DDD 是什么？限界上下文、聚合和微服务是什么关系？

知识点详解：先理解业务规则，再给模型划边界

统一语言，要出现在讨论和代码里

假设一个审批系统，把“已受理”“已批准”“已生效”都写成 success，很容易出现大家说成功却指不同阶段。

先和相关业务人员明确这些状态什么时候发生、谁能转换、哪些转换禁止，再让接口、测试和代码使用相同概念。

统一语言不是列完术语表就完成。规则变了，模型也要调整；开发者不能只依据数据库现有字段替业务定义全部含义。

限界上下文，是某套模型说得通的范围

假设内容运营的用户模型关心昵称、投稿和展示状态，风控用户模型关心风险证据与限制规则。它们可能指向同一个现实对象，却不必共享所有属性和变化流程。

可以通过明确标识与接口交换必要信息，避免一个巨大 User 对象被各部门共同修改。上下文之间还要约定事件、翻译和责任。

子域描述业务问题空间，上下文描述模型边界，两者不能机械认定永远一一对应。上下文也不一定直接等于一个微服务。

实体和值对象，看身份还是看内容

某个审批任务即使标题变化，仍是同一任务，需要持续身份，这是实体的思路。一个日期范围主要由开始与结束值及相关约束定义，可以作为值对象考虑。

值对象常设计为不可变，用新值表达变化，便于保持有效性；但不能因为一个类没有 id 字段就认定建模一定合理。

数据库实体解决持久化映射，领域实体表达业务身份和行为，两者可有不同结构。为了 ORM 便利而暴露任意 setter，可能绕过规则。

聚合控制一致性，别无限装大

假设审批任务要求“未批准不得生效”。如果状态和批准信息属于同一聚合，应通过根上的操作一起检查与变更，不让调用方随意改状态。

聚合边界应围绕必须一起保持的不变量，而不是“这些表都有外键”就全部合成一个巨大聚合。边界过大会扩大加载、锁和修改范围。

跨聚合协作需要明确协调和一致性要求，常通过应用层或事件组织，不能因为用了 DDD 就自动得到跨服务事务。

分层可以帮助表达，但不能替代讨论

应用层组织用例，领域层表达规则，基础设施实现存储与外部能力，是常见安排；项目不必强制使用完全相同目录名。

如果只有普通表单增删改查，套很多工厂、仓库和服务可能增加理解成本。复杂规则场景则可通过模型测试验证无效转换和不变量。

面试答案最好给出一个具体规则，再说明它的语言、模型范围和一致性边界。这样 DDD 才不是名词展示。

本题机制参考：Eric Evans DDD Reference、Fowler Bounded Context、Azure 战术 DDD。

面试官继续追问

DDD 必须配合微服务吗？

不是。模块化单体也可以采用 DDD，部署拆分是另外的架构决定。

聚合就是一张表吗？

不必，可能由多个对象构成；边界由业务一致性要求决定，不按表数定义。

领域服务就是所有业务逻辑的 Service 吗？

不是。适合表达不自然归属某个实体或值对象的领域操作，不是把行为全部从模型搬走。

面试速记卡

• 核心：围绕领域语言、模型和规则设计。
• 限界上下文：模型适用边界，不自动等于微服务。
• 实体：持续身份；值对象：内容与有效性。
• 聚合：根控制变化，保持内部不变量。
• 边界：DDD 不等于目录模板，也不替代跨服务事务。