限界上下文

限界上下文是领域驱动设计中的核心模式。它是 DDD 战略设计部分的重点，该部分侧重于处理大型模型和团队。DDD 通过将大型模型划分为不同的限界上下文并明确其相互关系来处理大型模型。

DDD 是关于根据底层领域的模型设计软件。模型充当 通用语言，帮助软件开发人员和领域专家进行沟通。它还充当软件本身设计（如何将其分解为对象或函数）的概念基础。为了有效，模型需要统一，即在内部一致，以便模型内部没有矛盾。

当您尝试对更大的领域进行建模时，构建单个统一模型会越来越难。在大型组织的不同部分，不同的人群会使用略微不同的词汇。建模的精确性很快就会遇到这种情况，通常会导致很多混乱。通常，这种混乱集中在领域的中心概念上。在我职业生涯的早期，我与一家电力公司合作 - 在这里，“电表”一词对组织的不同部门意味着略微不同的含义：它是电网与某个位置之间的连接，电网与客户之间的连接，还是物理电表本身（如果出现故障可以更换）。这些微妙的 多义词可以在对话中被淡化，但在计算机的精确世界中却不行。我一次又一次地看到这种混乱与“客户”和“产品”等多义词一起出现。

在那些年轻的日子里，我们被建议构建整个业务的统一模型，但 DDD 认识到我们已经了解到“大型系统的领域模型的完全统一将不可行或不经济” [1]。因此，DDD 将大型系统划分为限界上下文，每个上下文都可以拥有一个统一的模型 - 本质上是一种构建 多个规范模型 的方法。

限界上下文既有无关的概念（例如，支持票仅存在于客户支持上下文中），也有共享的概念（例如产品和客户）。不同的上下文可能对共同概念有完全不同的模型，并具有机制在这些多义概念之间进行映射以进行集成。几种 DDD 模式探索了上下文之间不同关系的替代方案。

各种因素在上下文之间划定了界限。通常，占主导地位的是人类文化，因为模型充当通用语言，当语言发生变化时，您需要不同的模型。您还会在同一个领域上下文中找到多个上下文，例如单个应用程序中内存模型和关系数据库模型之间的分离。这种边界是由我们表示模型的不同方式设置的。

DDD 的战略设计继续描述了您在限界上下文之间建立关系的各种方法。通常，使用上下文映射来描述这些关系是值得的。