本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书，可用于快速查找《领域驱动设计》中的诸多概念及其简明解释。
其它本系列其它文章地址：
[译文]Domain Driven Design Reference（一）—— 前言
[译文]Domain Driven Design Reference（二）—— 让模型起作用
[译文]Domain Driven Design Reference（三）—— 模型驱动设计的构建模块
[译文]Domain Driven Design Reference（四）—— 柔性设计
[译文]Domain Driven Design Reference（五）—— 为战略设计的上下文映射
绑定上下文
对一个特定模型的定义和适用范围(通常是一个子系统，或特定团队的工作)的描述。
上游-下游
两个组之间的关系是“上游”小组的行为影响“下游”小组的项目成功。但下游的行为并不会显著影响上游项目。（例如，如果两个城市沿着同一条河流，上游城市的污染主要影响下游城市。）
上游团队可以独立于下游团队的命运而取得成功。
相互依赖
必须在不同的上下文中交付两个软件开发项目以使其中任何一个被认为是成功的情况。（当两个系统各自依赖另一个系统的信息或功能时，我们通常会尽量避免将看到的项目构建成相互依赖的。 然而，也有一些相互依赖的项目，系统依赖性只向一个方向发展。当依赖系统没有其它的系统与该系统的集成时，它几乎没有任何价值，或许因为这是唯一一个使用它的地方，那么未能提供依赖系统就会导致两个项目都失败。）
自由
一个理想中的软件开发上下文，在其它上下文中的开发工作是成功或失败对其自己的交付没有什么影响。
上下文映射
为了策划战略，我们需要一个现实的，大范围的模型开发视图，扩展到我们的项目和我们整合的其他项目。
在没有全局视图的情况下，个别限界上下文会遗留下一些问题。其他模型的上下文可能仍然是模糊不清的。
其他团队的人不会意识到上下文的界限，并且会在不知不觉中做出一些模糊边缘或使内部连接复杂化的改变。当连接必须在不同的上下文中进行时，它们往往会相互渗透。
即使边界清晰，与其他上下文的关系也会限制模型的性质或可行的变化速度。这些制约因素需要通过非技术渠道表现出来，有时很难与他们正在影响的设计决策联系起来。
因此：
识别项目中正在使用的每个模型并定义它的限界上下文。这包括非面向对象子系统的隐式模型。给每个限界上下文命名，并且使其名称成为通用语言的一部分。
描述模型之间的联系点，列出对任何交互的明确翻译，突出任何共享、隔离机制和影响程度。
映射现有的领域范围。稍后再进行转换。
这张映射图可以成为实际设计策略的基础。
在接下来的几页中，关系的描述会变得更加具体，在限界上下文之间有一组通用的关系模式。
合作关系*
当两个上下文中的团队共同成功或失败时，通常会出现合作关系。
在相互独立的上下文中，相互依赖的子系统缺少协作会导致两个项目的交付失败。一个系统缺失的一个关键特性可能会使另一个系统无法交付。不符合其他子系统开发人员期望的接口可能导致集成失败。一个相互约定的接口可能会变得过于别扭，以致于减慢了客户端系统的开发速度，或者很难实现，从而减慢了服务端子系统的开发速度。失败带来了两个项目的失利。
因此：
如果两个上下文中的任何一个开发失败都将导致两个上下文的交付一起失败，则在负责这两个上下文的小组之间建立合作关系。制定协调发展和联合管理一体化的过程。
团队必须在其接口的演进上进行协作，以适应这两个系统的开发需求。应该安排相互依赖的feature，以便它们在同一版本中完成。
大多数情况下，开发人员不需要详细了解其他子系统的模型，但他们必须协调他们的项目计划。当一个上下文中的开发遇到障碍时，则需要联合研究这个问题，以找到一种紧急的设计解决方案，而不会过分地损害任何一方。
此外，还需要一个清晰的过程来管理集成。例如，可以定义一个特殊的测试套件，以证明接口符合客户端系统的期望，它可以作为服务器系统上持续集成的一部分运行。
共享内核共享模型和相关代码的一部分是非常密切的相互依赖关系，它能够加快设计工作或者破坏这些共享的东西。