为什么你的 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