初窥Bounded Context

Bounded Context(限界上下文)是DDD中最难解释的原则，但或许也是最重要的原则。可以说，没有Bounded Context，就不能做DDD。

Bounded Context是领域驱动设计中战略设计的重要组成部分，一定程度上决定了系统的逻辑架构以及集成方式。基于康威定律，Bounded Context的划分也可能会影响项目的组织结构。DDD社区将Bounded Context定义为：

应该显式地定义某个模型所应用的上下文。还应该在团队组织、应用中特定部分的使用以及像代码库和数据库模式等物理表现等方面显式地设定边界。要保持边界中模型的严格一致，而不要受外界问题的影响与干扰。

这段话表达了一个关键概念是“边界”，这与软件设计中“分而治之”的思想有关。通过为领域模型划定合理的边界，就可以降低设计与开发的复杂度。此外，边界还能够划分知识的层次，例如对外而言，可以只保障暴露在边界外接口的一致性，以及关注它们之间的集成方式。边界之内则自成一体，可以独立演化，甚至可以包容一到多个遗留模块。

正是因为Bounded Context带来的隔离性，Juelin Lerman才认为：“把一个将大量的类放在一个上下文中的独立模型分解为多个较小的模型是有好处的。Bounded Context创建的模型较小，而且内聚性更高，同时维持了模型之间的边界。”

于是，Bounded Context在DDD中的重要性也就凸显，DDD社区逐渐认识到了这一点。Mike在文章《DDD: The Bounded Context Explained》中认为：Bounded Context是DDD中最难解释的原则，但或许也是最重要的原则。可以说，没有BC，就不能做DDD。在了解Aggregate Root、Aggregate、Entity等概念之前，需要先了解BC。

重要性凸显了，然而问题也随之而来。几个问题如乌云一般盘旋在我的头顶，驱使我思考Bounded Context的本质。问题如下：

• 如何确定或划分Bounded Context？
• Bounded Context是否具有层次？
• Bounded Context划分的边界是逻辑的，还是物理的？
• Bounded Context之间的通信方式？

为了解决如上问题，我查阅了许多书籍与资料，也从项目实践中去探索。在回答这些问题之前，我先抛出一些概念知识。

Vaughn Vernon的大作Implementing Domain-Driven Design解释了他对Bounded Context的理解：

Bounded Context是一个显式的边界，领域模型便存在于这个边界之内。领域模型把通用语言表达成软件模型。创建边界的原因在于，每一个模型概念，包括它的属性和操作，在边界之内都具有特殊的含义。

▲ Vaughn Vernon | 实现领域驱动设计

Mike同样认为一个上下文意味着一个专有的职责，而且BC之间应该是解耦的，彼此并不知道。一个BC并不知道另一个BC的内部，但这两个BC都可以使用Common Objects（DTOs）来完成彼此之间的通信；或者使用专用的Adapter。

这里事实上谈到的是BC的设计原则，它与OO设计原则一脉相承。在文章《Bounded Contexts as a Strategic Pattern Beyond DDD》中，作者提到了开发者可以应用GRASP原则来设计Bounded Context，尤其是低耦合、高内聚与信息专家模式。

就在这篇文章中，作者还提到了BC与Domain之间的关系:

Bounded Context的一个显著特点在于它与Domain匹配。因此，它体现的是高层的抽象机制。Bounded Context并非编程语言或框架的产出工件，而是体现了人们对领域思考的本质。

结合这些知识，我们可以这样描述Bounded Context的特征：

• BC是模型概念，与实现无关，是高层的抽象机制
• 具有自己独立的边界，是自治的，遵循高内聚、松耦合
• BC之间的关系决定它们之间的协作与通信方式
• 它与Domain应为一一对应关系
• 一个上下文意味着一个专有的职责

要驱动出Bounded Context，毫无疑问需要与领域专家交流，通过提炼统一语言，来创建BC。然而，统一语言的建立固然有助于进一步深化和细化领域模型，但并不能直接帮助我们创建BC。从Bounded Context到Context Map的设计过程并非单向的，而是一个螺旋演进的过程。