共计 1235 个字符，预计需要花费 4 分钟才能阅读完成。
概念
界限上下文是指一个清晰可见的边界勾勒出的上下文，它是动态的业务被静态切分的产物。它代表了一个独立的子领域，具有自己的内部模型、业务逻辑和语言，与其他界限上下文之间通过明确的接口进行交互。每个界限上下文都有自己的边界，这是一个由业务需求驱动的设计决策。
界限上下文的定义和结构
界限上下文对内封装了业务知识和领域对象，对外提供了业务能力，界限上下文是最基本的自治架构单元。一个界限上下文是完备的，是稳定的，是能够独立进化的。
上图展示了界限上下文的结构和界限上下文之间的关系，可以看出界限上下文之间是可以互相存在依赖关系的。界限上下文之间依赖的“接口”是业务能力，意味着界限上下文A不能直接去访问界限上下文B内部的某个领队知识，而是只能通过B对外暴露的业务能力接口来完成对能力的组装。
界限上下文对协作的影响
如果界限上下文之间存在协作关系，必然是某种原因导致了这种协作关系。从依赖的角度看，这种协作关系是因为一方需要知道另一方的知识，这种知识包括：
-
领域行为：需要判断导致行为之间的耦合原因是什么？如果是上下游关系，要确定下游是否就是上游服务的真正调用者。
-
领域模型：需要重用别人的领域模型，还是自己重新定义一个模型。
-
数据：是否需要界限上下文对应的数据库提供支撑业务行为的操作数据。
所谓领域行为，具体到设计层面，就是每个领域对象的职责，职责可以由实体（Entity）、值对象（Value Object）来承担，也可以是领域服务（Domain Service）或者资源库（Repository）乃至工厂（Factory）对象来承担。
如果我们选择后两种履行职责的形式，就必然牵涉到对象之间的协作。一个好的设计，职责一定是分治的，就是让每个高内聚的对象只承担自己擅长处理的部分，而将不擅长的职责转移到别的对象。
如何划分界限上下文
- 确定模型或系统的功能和范围。明确该模型或系统要解决什么问题，需要包含哪些功能和组件。
- 将模型或系统分解为较小的组成部分。这些部分应该相对独立，可以在不同的上下文中进行设计和实现。
- 为每个部分定义一个限界上下文。限界上下文应该明确该部分的功能和范围，以及与其他部分的边界。
- 确定每个限界上下文之间的关系。这些关系可以是聚合、组合、关联等，取决于模型或系统之间的关系。
- 定义通用语言和领域对象。在每个限界上下文中，应该定义一组特定的术语、词组或句子，以描述该上下文中的领域对象和概念。
- 实现每个限界上下文。在实现时，应该遵循界限上下文的定义，确保该部分与其他部分之间的边界是清晰的和可维护的。
总结
限界上下文是架构推演的基础单元，这个推演既包含了从业务架构到应用架构的推演，也包含了从业务架构到团队架构的映射，是架构设计中一个非常重要的概念，理解清楚了这个概念，针对哪怕规模再大的业务域，也有了一把能将其解构的手术刀。限界上下文的内部又包含了领域对象和领域知识，因而对于后续我们接触到的那些更加细粒度的建模概念，也知道了他们在整个架构全局视角下的位置，不会只见一叶，不见泰山了。
