有界上下文

  有界上下文

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

 

 

DDD 是基于底层领域模型来设计软件。模型充当通用语言，帮助软件开发人员和领域专家之间的沟通。它还充当软件本身设计的概念基础 —— 软件如何分解为对象或功能。
为了有效，模型需要统一 —— 即内部一致，以便内部不存在矛盾。

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

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

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

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

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

 进一步阅读

DDD 的规范来源是 Eric Evans 的书。它不是软件文献中最容易阅读的，但它是一本能充分回报大量投资的书。有界上下文打开第四部分（战略设计）。

Vaughn Vernon 的《实施领域驱动设计》从一开始就专注于战略设计。第 2 章详细讨论了如何将域划分为有界上下文，第 3 章是绘制上下文映射的最佳来源。

Verraes 和 Wirfs-Brock 讨论了描述有界上下文的一些微妙之处，特别是在上下文可能因历史和人际关系以及领域概念而需要分割的情况下。

我喜欢既古老又仍然相关的软件书籍。我最喜欢的此类书之一是威廉・肯特的《数据与现实》。我仍然记得他对油井多义词的简短描述。

Eric Evans 描述了有界上下文的显式使用如何允许团队使用气泡上下文在遗留系统中嫁接新功能。该示例说明了相关的有界上下文如何具有相似但不同的模型，以及如何在它们之间进行映射。

 笔记

1：领域驱动设计中的 Eric Evans