领域驱动设计-有界上下文

本文译自马丁福勒的文章“BoundedContext”https://martinfowler.com/bliki/BoundedContext.html

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

 

 

 

 

DDD 是关于基于底层域模型设计软件。模型充当UbiquitousLanguage以帮助软件开发人员和领域专家之间的交流。它还充当软件本身设计的概念基础 - 如何将其分解为对象或功能。为了有效，模型需要统一——即内部一致，这样就不会出现矛盾。

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

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

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

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

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