限界上下文是业务共识而非技术划分，domain包只放行为不放结构体，聚合根须通过工厂函数创建并封装状态变更，跨上下文通信仅通过DTO或领域事件，所有测试应隔离外部依赖且快速完成。
domain 包不是放结构体的地方，而是业务语义的唯一出口。所谓“完美解耦”，不在于模块数量多或分层多，而在于每个模块能独立演进、测试、部署——前提是业务边界被真实识别出来，且技术实现不越界。
先识别限界上下文，别急着建包
限界上下文（Bounded Context）不是技术划分，是业务共识。比如“用户”在登录流程里是 User（含密码哈希、登录态），在订单流程里只是 UserID（只读标识），在风控流程里可能是 RiskProfile（行为评分、设备指纹）。这三个不是同一个“用户”，强行共用一个 models.User 结构体，等于把不同上下文的语言混在一起说。
实操建议：
- 和业务方一起画出核心业务流程图，标出每个环节中“用户”代表什么、谁修改它、谁只读它
- 对每个语义差异点打上标签，如
auth.User、order.CustomerID、risk.Profile - 拒绝跨上下文直接引用结构体：禁止
order/internal/service.goimportauth/internal/model - 上下文间通信只走明确定义的 DTO 或领域事件，例如
user.RegisteredEvent发布后，order模块通过自己的CustomerProjection建立只读快照
internal/domain 里只放行为，不放字段
Go 没有 class，但 domain 包必须承担类的职责：封装状态 + 强制校验 + 显式变更。把 Order 定义成带 Status 字段的 struct 是错的起点；正确的做法是让它只暴露 Confirm()、Cancel() 等方法，内部用私有字段 + 不变量检查控制流转。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 外部代码直接写
order.Status = "shipped"，绕过发货前库存校验 - DTO 绑定时用
json:"status"直接映射到 struct 字段，导致 domain 层失去控制权 - 测试时 mock 一个空 struct 就调用方法，结果 panic —— 因为没走构造函数
NewOrder()
实操建议：
- 所有聚合根必须通过工厂函数创建，如
order.New(orderID, items)，构造时即校验 - 状态变更全部封装为方法，且方法名体现业务意图：
order.Ship()而非order.SetStatus("shipped") - 值对象（如
Money、SKUCode）必须不可变，提供New()构造并拒绝非法输入（如负金额、空字符串） - 禁止在
domain包里出现database/sql、gin.Context、http.Request等基础设施类型
用小接口隔离依赖，别让 repository 污染 domain
定义 type OrderRepository interface { Save(Order) error; FindByID(ID) (*Order, error) } 看似解耦，实则危险：它把持久化细节（如事务、锁、分页）提前泄露给了 domain 层。真正该由 domain 决定的，是“我需要一个地方存住这个 Order”，而不是“我要调 Save 方法”。
实操建议：
- domain 层只定义能力契约，例如
type OrderStorer interface { Store(o Order) error }，名字不暴露实现语义 - application 层协调时，注入具体实现（如
MySQLOrderStorer），但 domain 层完全不知其存在 - 避免在 domain 方法签名中暴露 infrastructure 类型：禁止
func (o *Order) ApplyDiscount(db *sql.DB) error - 跨上下文协作不靠接口传参，而靠事件：如
order.Created事件触发inventory.DeductStock，两者无编译期依赖
测试驱动不是口号，是模块边界的探针
如果一个 domain.Order 的单元测试要启动 MySQL、mock HTTP client、加载 config.yaml，说明边界已经失守。真正的 domain 测试应该只依赖 Go 标准库和你自己的 domain 包。
实操建议：
- 每个 domain 模块的
go test必须在 100ms 内完成，否则检查是否意外引入了外部依赖 - repository 接口的测试放在 infrastructure 层，用内存实现（
memrepo.OrderRepo）验证契约 - application 层测试只 mock domain 接口，验证编排逻辑（如“下单失败时是否发布了
OrderFailed事件”） - 禁用
_空导入，所有依赖必须显式声明；gomod tidy 后检查是否有非标准库的间接依赖出现在 domain 模块中
marketing 上下文中剥离，升格为独立上下文，并拥有自己的 membership domain 模块。解耦不是一次性的架构动作，而是持续识别业务语义漂移的过程。 
