当功能集成受到限制时，大型上下文的持续集成的开销可能会被认为太高。当团队没有足够的技能或组织架构来维持持续集成，或者单个团队的规模太大而笨拙时，这种情况可能尤为明显。因此，可以定义独立的限界上下文，并形成多个团队。
一旦独立的、不协调的团队在密切相关的应用程序上工作，可能会向前推进一段时间，但是他们生产的产品可能不适合在一起。即使是合作伙伴团队最终也会花费大量精力在翻译层和改造上，同时重复这些工作并失去通用语言的好处。
因此：
用明确的边界指定团队同意分享的领域模型的一部分子集。保持这个内核尽可能的小。
在这个边界内，包括模型的子集，代码的子集，或者与该模型的部分相关联的数据库设计。这种显式共享的内容具有特殊的地位，在未与其他团队协商的情况下不应改变。
定义一个持续集成过程，以保持内核模型的紧凑性，并与团队的通用语言保持一致。经常其整合功能系统，虽然比团队中持续集成的次数要少一些。
客户/供应商开发
当两个团队处于上下游关系时，上游团队可能独立于下游团队的命运而取得成功，下游的需求将以各种各样的方式得到解决，并带来广泛的负面后果。
下游的团队可能是无助的，受上游优先级的摆布。与此同时，上游团队可能会收到抑制，担心会破坏下游系统。拥有复杂审批流程的繁琐的变更请求过程并没有改善下游团队的问题。如果下游团队对变更拥有否决权，上游团队的自由发展就会停止。
因此：
在两个团队之间建立清晰的客户/供应商关系，意味着将下游优先因素放到上游的规划中。为下游需求进行谈判和预算任务，以便每个人都了解承诺和时间表。
敏捷团队可以在规划会议中让下游团队扮演上游团队的客户角色。联合开发的自动化验收测试可以验证来自上游的预期接口。将这些测试添加到上游团队的测试套件中，作为其持续集成的一部分，将使上游团队自由地进行更改，而不必担心下游的副作用。
顺从者
当两个开发团队有一个上下游关系时，上游没有动力为下游团队的需求提供帮助，下游团队就无能为力了。利他主义可能会促使上游开发者做出承诺，但它们不太可能实现。相信这些好意会导致下游团队基于无法获得的特性来制定计划。下游项目将被推迟，直到团队最终学会接受上游所提供的东西。针对下游团队的需求量身定制的接口是不太不可能的。
因此：
通过对上游团队的模型进行严格的遵守，消除了限界上下文之间的转换的复杂性。尽管这限制了下游设计人员的风格，并且可能不会产生应用程序的理想模型，但是选择一致性极大地简化了集成。此外，你将与上游团队共享一种通用语言。上游在驾驶员的位置上，所以让他们的交流变得容易是件好事。利他主义可能足以让他们与你分享信息。
反腐层
当与合作团队衔接良好设计的限界上下文时，翻译层可以是简单的，甚至是优雅的。但是，当控制或通信不足以实现共享内核、合作伙伴或客户供应商关系时，转换就变得更加复杂。翻译层采用了一种更具防御性的语气。
一个提供给上游系统的大型接口最终可能完全颠覆下游模型的意图，从而使其被修改成以一种特别的方式来模仿其他系统的模型。遗留系统的模型通常是很薄弱的(如果不是大泥球的话)，即使是明确设计的例外也可能不符合当前项目的需求，这使得遵循上游模型变得不切实际。然而，这种集成对于下游项目可能非常有价值甚至是必需的。
因此：
作为下游客户端，创建一个隔离层，根据您自己的领域模型，为系统提供上游系统的功能。该层通过其现有的接口与另一个系统进行通信，只需要很少或不需要对其他系统进行修改。在内部，这一层在两个模型之间需要单向或双向转换。
开放主机服务
通常对于每个限界上下文，您将为每个部件定义一个翻译层，您必须将其与上下文之外的组件集成在一起。在集成是一次性的情况下，为每个外部系统插入翻译层的这种方法以最小的成本避免了模型的损坏。但是当你发现你的子系统有更高的要求时，你可能需要更灵活的方法。