ddd-bounded-context

一句话概述

限界上下文是一个明确的边界，在其范围内，单一模型及为其命名的通用语言保持一致且完整。

何时使用此技能

• 同一个名词在系统的不同部分表示不同的事物（销售中的“客户”和支持中的“客户”）。
• 模型日渐错综复杂，单独的更改会以意想不到的方式产生连锁影响。
• 团队边界与代码边界不一致。
• 团队正在讨论“要不要把它做成独立服务？”

何时不使用此技能

• 上下文内部的重构——交由战术模式技能处理。
• 关于上下文之间如何关联的问题 → 转到 ddd-context-mapping。
• 在整个业务范围内分配建模工作 → 转到 ddd-subdomain-classification。

核心内容

限界上下文是概念上的边界，不受部署方式限制。它是模型能够保持整体性的范围。它可以是模块、包、微服务，也可以是整个系统——关键在于，边界内部的每个术语都只有一种含义，每条规则都保持一致。

需要划定边界的信号。

• 同一个词在系统的不同部分表示不同的事物。
• 模型的两条规则会根据当前运行的代码区域而相互矛盾。
• 两个团队总在彼此对“同一个”模型所做的更改上发生冲突。
• 面向一类用户的 UI 与面向另一类用户的 UI 截然不同，却调用了相同的领域代码。

上下文与微服务。 限界上下文是模型边界；微服务是部署边界。两者通常重合，但不一定如此。单个服务可以承载两个上下文（通过模块边界保持隔离）。两个服务也可以实现同一个上下文（这种情况很少见，通常是个错误）。

为边界命名。 为每个上下文取一个能体现其业务目的的名称：销售、计费、配送、身份。避免使用技术性名称（Backend、Core）。领域专家应能理解这个名称。

决策启发

• 在项目初期，优先采用更少、更大的上下文。拆分成本低，合并成本高。
• 当术语无法调和地冲突、团队需要自主权或模型规则相互矛盾时，再进行拆分。
• 不要假设每个微服务对应一个限界上下文。映射关系由模型决定，而不是由部署拓扑决定。

反模式

• 按每张数据库表划分一个限界上下文——这只是表面功夫，并没有真正划定模型边界。
• 忽视边界，直到模型出现问题——届时清理将成为一个大型项目。
• 将“限界上下文”视为“微服务”的同义词。
• 划定边界，却不给其中的通用语言命名。

另请参阅

• ddd-ubiquitous-language — 边界内包含什么。
• ddd-context-mapping — 上下文之间如何关联。
• ddd-subdomain-classification — 哪些上下文最值得投入精力。

参考资料

• Evans，Domain-Driven Design（2003），第 14 章（维护模型完整性）。