ddd在go中无标准框架，需用包隔离限界上下文、方法封装聚合状态变更、接口解耦跨上下文依赖、返回事件列表而非直接发布。
DDD在Go里没有“标准框架”，别找go-ddd这种不存在的包
Go语言本身不提供DDD原生支持，也没有官方或主流社区维护的ddd模块。你搜到的所谓“Go DDD框架”基本是个人项目、半成品，或只是目录结构模板。真正落地DDD，靠的是约束力——用Go的包管理、接口定义、不可导出字段和显式依赖传递来模拟限界上下文、聚合根、领域服务等概念。硬套Java/C#那套抽象层（比如泛型仓储基类、自动扫描实体）反而会让代码更难读、更难测。
聚合根必须控制状态变更入口，用func (*Order) Confirm()而非order.Status = "confirmed"
这是Go实现聚合根最易被忽略的一点：领域逻辑必须封装在方法内部，禁止外部直接写字段。否则无法保证不变量（如“已取消的订单不能再次发货”）。
常见错误：
- 把
Status设为导出字段（首字母大写），导致任意包都能赋值 - 在Handler或Service里直接修改
order.Status = "shipped"，绕过领域逻辑 - 确认发货前没校验库存，把校验逻辑放在API层而不是
(*Order).Ship()里
正确做法是：所有状态变更走小写方法，内部做校验+副作用标记（如o.shippedAt = time.Now()），返回error而非bool。例如：
func (o *Order) Ship(inventory InventoryService) error {
if o.Status != "confirmed" {
return errors.New("order must be confirmed before shipping")
}
if !inventory.HasStock(o.Items) {
return errors.New("insufficient inventory")
}
o.Status = "shipped"
o.ShippedAt = time.Now()
return nil
}
限界上下文用package隔离，但跨上下文调用必须走interface而非具体类型
Go里一个限界上下文对应一个package（如order、payment、inventory），但它们之间不能直接import对方的struct。否则会形成隐式耦合，破坏上下文边界。
实操要点：
- 跨上下文协作只通过本上下文定义的
interface（如order包定义type InventoryChecker interface { HasStock([]Item) bool }） - 具体实现由上层（如
application包）注入，order包完全不知道inventory包的存在 - 避免在
order包里importinventory，哪怕只是为接收参数类型
否则你会遇到：改inventory.Item字段名，导致order包编译失败——这不是DDD，是包耦合。
领域事件用func()回调而非chan或第三方消息队列直接嵌入聚合
很多教程让聚合根直接发消息到chan，这会让聚合变得不可测试、难以回放，也违背“聚合只关心自身一致性”的原则。
推荐方式是：聚合方法返回事件列表（[]any或自定义type DomainEvent interface{}），由调用方决定如何处理：
func (o *Order) Confirm() ([]DomainEvent, error) {
if o.Status != "draft" {
return nil, errors.New("only draft orders can be confirmed")
}
o.Status = "confirmed"
return []DomainEvent{&OrderConfirmed{ID: o.ID, ConfirmedAt: time.Now()}}, nil
}
这样测试时可断言事件内容；生产中由Application Service统一收集并分发（同步调用领域服务 / 异步推到Kafka）。强行在聚合里启动goroutine或写chan，等于把基础设施细节拖进核心领域。
复杂点在于：事件发布顺序、重试、幂等这些事，得由外层兜底，不是聚合该管的。很多人卡在这一步，以为“DDD就得自带事件总线”，其实Go里最轻量可靠的方案，就是让Application层负责组装和调度。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
