1. 为什么我们需要从六边形架构走向DDD
六边形架构(Hexagonal Architecture)最早由Alistair Cockburn在2005年提出,它通过将核心业务逻辑与外部依赖隔离来解决传统分层架构的耦合问题。我在多个Go项目中实践发现,当业务复杂度达到一定规模时,纯粹的六边形架构会暴露出三个典型痛点:
- 领域逻辑分散:订单处理逻辑可能分散在20多个handler中,修改一个运费计算规则需要全局搜索
- 架构约束失效:随着团队扩张,新人可能直接把数据库模型传到UI层,导致防腐层形同虚设
- 演进成本高昂:当需要将单体拆分为微服务时,业务逻辑与框架代码的纠缠会导致重构如同重写
这时领域驱动设计(DDD)的价值就显现出来了。去年我们重构一个电商平台时,通过DDD的限界上下文划分,将原来5万行的单体服务拆分为订单、库存、支付等明确边界的内聚模块,代码重复率下降了62%。但直接全盘采用DDD又会面临Go语言特有的挑战:
go复制// 典型的六边形架构Go代码示例
type OrderService struct {
repo OrderRepository // 接口定义
}
func (s *OrderService) Create(order *Order) error {
// 业务逻辑与基础设施混杂
if err := s.validate(order); err != nil {
return err
}
if err := s.repo.Save(order); err != nil {
return s.retry(order) // 包含基础设施重试逻辑
}
return nil
}
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Go语言下的渐进式演进路线
2.1 阶段一:六边形架构的规范化改造
首先在现有六边形架构基础上建立明确的依赖规则。我们创建了internal目录结构:
code复制/internal
/domain # 领域模型
/app # 应用服务
/adapter # 适配器实现
/client # 外部服务客户端
关键改造点是引入依赖注入框架。经过对比wir
