领域模型如何落地：分层、聚合与上下文边界

领域模型落地的难点不在于“有没有实体类”，而在于规则放在哪里、事务边界在哪里、不同上下文之间如何协作。

问题背景

很多项目表面上有 Domain 层，但规则散落在 Controller、Service、SQL 和前端校验里。结果是任何一个业务规则变化，都要在多处找实现。

核心概念

分层解决职责边界，聚合解决一致性边界，限界上下文解决语义边界。三者缺一不可。

flowchart TB
    A["接口层"] --> B["应用层"]
    B --> C["领域层"]
    C --> D["聚合 / 值对象 / 领域服务"]
    B --> E["基础设施层"]
    E --> F["数据库 / 消息 / 外部服务"]

实际工程场景

例如审批系统里，审批单能否提交不是简单字段校验，而是由状态、申请人权限、金额阈值和流程配置共同决定。这个规则应进入领域模型，而不是散落在 API 层。

常见误区

• 聚合设计过大，把所有关联对象都塞进一个事务。
• 只按数据库外键设计对象关系。
• 让应用服务承载所有业务判断，领域对象只剩 getter/setter。

最佳实践

• 聚合只保护必须强一致的规则。
• 跨聚合协作用事件或应用服务编排。
• 领域对象方法名使用业务语言。
• 每个上下文都允许拥有自己的模型，而不是共享一个全局模型。