当一个子系统必须与许多其他的子系统集成时，为每一个子系统定制一个翻译对象可能会使团队陷入困境。有越来越多的维护，越来越多的担心什么时候会发生变化。
因此：
定义一个协议，将访问您的子系统作为一组服务。 打开协议，使所有需要与您集成的人都可以使用它。增强和扩展协议以处理新的集成需求，除非一个团队有特殊的需求。然后，使用一次性翻译对象来增强该特殊情况的协议，以便共享协议能够保持简单和一致。
这将使服务提供者处于上游位置。每个客户端都在下游，并且通常其中一些客户端会遵守规定，有些客户端会建立反腐层。具有开放主机服务的上下文可能与它的客户端以外的上下文有任何关系。
公共语言
两个限界上下文模型之间的转换需要一种通用语言。
直接转换到现有的领域模型可能不是一个好的解决方案。这些模型可能过于复杂或被分解得很糟糕。也许他们说的是非法的。如果将其中一种用作数据交换语言，它实际上就会被冻结，不能响应新的开发需求。
因此：
使用一种文档完整的公共语言，可以将必要的领域信息作为一种通用的通信媒介来表达，并根据需要翻译为该语言。
许多行业以数据交换标准的形式建立了公共语言。项目团队也开发自己的，在他们的组织内使用。
公共语言通常与开放主机服务相结合。
分而治之
在定义需求方面，我们必须冷酷无情。如果两组功能之间没有显著的关系，它们可以完全相互分离。
整合总是代价很大的，有时候好处很小。
因此：
声明一个限界上下文，使其与其他上下文完全没有关联，允许开发人员在这个小范围内找到简单的、专门的解决方案。
大泥球
在我们调查现有的软件系统时，我们试图了解不同的模型在定义的边界内是如何被应用的，我们发现部分系统（通常是大型系统），模型是混合的，边界是不一致的。
在没有边界的系统中，试图描述模型的上下文边界很容易陷入困境。
定义良好的上下文边界作为知识选择和社会力量的结果出现(尽管创建系统的人在当时可能并不总是有意识地意识到这些原因)。当这些因素缺失或消失时，将多个概念系统混合在一起，使得定义和规则变得模棱两可或相互矛盾。随着特性的添加，系统是根据附加的逻辑来工作的。依赖关系纵横交错。因果关系变得越来越难以追踪。最终，软件会凝结成一个大的泥球。
在某些情况下，大球泥实际上是非常实用的（正如Foote和Yoder的原文所描述的那样），但它几乎完全阻止了有用模型所需要的敏锐和精确性。
因此：
在整个混乱的周围画一个边界，把它指定为一个大泥球。不要尝试在此上下文中应用复杂的建模。要警惕这种系统向其他上下文蔓延的趋势。
（见。Brian Foote和Joseph Yoder）
作者：Zachary_Fan
出处：
如果你想及时得到个人自写文章的消息推送，欢迎扫描下面的二维码~。