限界上下文是业务语义边界，直接对应cmd目录、gRPC服务名和数据库名三者一致；Go中通过interface定义契约、聚合靠方法封装与根实体控制、领域事件须在事务提交后由仓储统一发布。
Go 微服务与 DDD 结合不是为了套概念，而是解决一个实际问题：当业务逻辑开始跨 service、跨 handler、跨 util 处处散落时，你改一个“订单超时取消规则”，得翻 5 个包、改 3 个函数、补 2 个测试——这时候，DDD 的限界上下文和聚合就是你的刹车片和路线图。
如何用限界上下文（Bounded Context）切分 Go 微服务边界
限界上下文不是文档里的虚词，它直接对应你 cmd/ 下的服务目录名、gRPC service 名、数据库 schema 名，三者必须一致。比如电商系统里“库存”上下文，就该有：
-
cmd/inventory-service—— 独立可部署的二进制入口 -
pb/inventory/v1/inventory.proto中定义InventoryService - 专属 PostgreSQL 数据库
inventory_db，不与其他服务共享表
常见错误是把“用户”上下文拆成 auth-service 和 profile-service，结果两者都读写 users 表——这已经违反了限界上下文的封装性，本质上是分布式单体。真正合理的切分应基于业务能力，比如“用户认证”和“用户资料编辑”在领域语言里本就是两套规则、两种生命周期。
Go 里怎么组织聚合（Aggregate）而不依赖继承
Go 没有 class 继承，但聚合的核心是“一致性边界”和“根实体控制访问”，不是语法糖。以 OrderAggregate 为例，关键不在结构体嵌套，而在约束力：
立即学习“go语言免费学习笔记（深入）”；
- 所有对
OrderItem的增删改必须通过Order根实体方法，如order.AddItem(item)，禁止外部直接操作item切片 -
Order自带Validate()方法，校验状态迁移（如“已支付”不能退回到“待支付”） - 仓储
OrderRepository接口只暴露Save(ctx, agg *OrderAggregate)和FindByID(ctx, id) (*OrderAggregate, error)，不提供按item.sku查询等越界操作
很多人误以为聚合=struct 嵌套，结果写出 type Order struct { Items []Item } 就完事——这只是一个数据容器，不是聚合。真正的聚合必须靠方法封装+接口隔离来守住边界。
领域事件（Domain Event）在 Go 微服务中怎么落地才不翻车
领域事件不是发个消息就完事，它本质是“聚合内部状态变更后，对外广播的不可变事实”。在 Go 中最容易踩的坑是：
- 在聚合方法里直接调用
publish.Event(...)—— 这会让仓储事务和事件发布耦合，一旦 DB 提交失败，事件却已发出，状态不一致 - 把事件类型定义在
pkg/event这种全局包里 —— 导致所有服务都 import 同一套 event，失去上下文隔离
正确做法是：聚合内部只收集事件（agg.AddDomainEvent(&OrderPaid{...})），由仓储实现（如 pgOrderRepository.Save）在 DB 事务提交成功后，统一调用消息队列客户端推送。事件结构体定义在聚合所在 domain 包内，例如 domain/order/event.go，其他服务只能通过 DTO 或 gRPC message 消费，不能直接 import 领域事件类型。
为什么 Go 的 interface + 依赖注入是 DDD 在微服务中最自然的载体
DDD 分层（领域层、应用层、基础设施层）在 Go 里不是靠文件夹命名撑起来的，而是靠 interface 的声明位置和实现位置分离：
- 领域层只定义
type PaymentService interface { Charge(ctx context.Context, orderID string) error }，不关心实现 - 应用层（usecase）组合领域接口和 infra 实现，例如
placeOrderUsecase里注入paymentSvc PaymentService和orderRepo OrderRepository - 基础设施层（如
infra/stripe）提供具体实现，且只 import 应用层或领域层接口，绝不可反向依赖
这种结构让单元测试极轻量：应用层用例可以传入 mock 实现，完全绕过 Stripe API 或数据库。而很多团队把 Stripe 调用硬编码在 service 里，导致一跑测试就得连外网——这不是 DDD 落地失败，是没理解 interface 在 Go 里承担的架构职责。
最常被忽略的一点：DDD 在 Go 微服务中不是从写代码开始的，而是从跟产品/运营一起白板画出“订单生命周期状态图”“库存扣减决策树”开始的。代码只是那个共识的副产品；没有通用语言，再工整的 domain/ 目录也只是一堆自嗨的 struct。
