一个企业应用有多个模型，每个模型有自己的界定的上下文。建议用上下文作为团队组织的基础。在同一个团队里的人们能更容易地
沟通，也能很好地将模型集成和实现。但是每个团队都工作于自己的模型，所以最好让每个人都能了解所有的模型。上下文映射
（Context Map）是指抽象出不同界定上下文和它们之间关系的文档，它可以是像下面所说的一个试图（Diagram），也可以是其他任
何写就的文档。详细的层次各有不同。它的重要之处是让每个在项目中工作的人都能够得到并理解它。

如图：


只有独立的统一模型还不够。它们还要被集成，因为每个模型的功能都只是整个系统的一部分。在最后，单个的部分要被组织在一
起，整个的系统必须能正确工作。如果上下文定义的不清晰，很有可能彼此之间互相覆盖。如果上下文之间的关系没有被抽象出来，
在系统被集成的时候它们就有可能不能工作。

每个界定的上下文都应该有一个作为Ubiquitous Language 一部分的名字。这在团队之间沟通整个系统的时候非常有用。每个人也应
该知道每个上下文的界限以及在上下文和代码之间的映射等。一个通常的做法是先定义上下文，然后为每个上下文创建模型，再用一
个约定的名称指明每个模型所属的上下文。

在接下来的章节中，我们要讨论不同上下文之间的交互。我们会列举很多可用来创建上下文映射的模式，被创建的上下文有清晰的角
色和被指明的关系。在上下文之间，共享内核（Shared Kernel）和客户-供应商（Customer-Supplier）是具有高级交互的模式。隔离通
道（Separate Way）是在我们想让上下文高度独立和分开运行时要用到的模式。还有两个模式处理系统和继承系统或者外部系统之间
的交互，它们是开放主机服务（Open Host Service）和防崩溃层（Anticorruption Layer）。