为什么你的 Service 越写越复杂？一次从三层到六边形架构的真实 Go 重构

很多业务系统的问题，并不是“架构选错了”，而是在不知不觉中，把所有复杂度都塞进了 Service 层。当你发现：改一个需求要动好几个 Service测试一个方法要 Mock 一堆依赖新同事最怕改核心逻辑那说明系统已经不是“功能问题”，而是结构问题了。这篇文章，我会用一个真实业务场景，带你完整走一遍：Service 是如何一步步失控的，以及六边形架构是如何帮我们止住这种失控的。一、Service 失控，并不是因为你写得不好我们先看一段非常“正常”的代码结构及代码实现：├── controller │ └── order_controller.go ├── service │ └── order_service.go ├── repository │ └── order_repo.go type OrderService struct { repo *OrderRepo risk *RiskClient sms *SmsClient } func (s *OrderService) CreateOrder(req *Req) error { // 参数校验 if req.Amount = 0 { return errors.New("invalid am