领域驱动设计入门：DDD上下文中，领域是什么？

2022-08-1122:46:25软件工程与架构Comments1,129 views字数 3314阅读模式

领域驱动设计（DDD）是由 Eric Evans 发明的一个概念。他在 2004 年出版的《领域驱动设计》一书（即”大蓝皮书“）中探讨了这个概念。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

那么在 DDD 上下文中，领域是什么？文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

领域是知识、影响或活动的范围。用户应用程序的主题域即软件的领域。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

我将概要地介绍下 DDD 的方方面面。本文将探讨 DDD“为什么？”和“是什么？”。在这里，我不会深入探讨具体的主题。不过，我会说明重要术语的定义，就像上面的“领域”。你会发现，共享词汇也是 DDD 本身的一部分。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

首先，你要问自己，这些概念是否仍然有效？文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

DDD 的意义

DDD 不是一种特定的技术，它是一个概念。许多现代概念都直接使用 DDD。下面这段话出自 Sam Newman《微服务设计》一书的第一页。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

Eric Evans 的《领域驱动设计》一书帮助我们理解了用代码呈现真实世界的重要性，并且告诉我们如何更好地进行系统建模。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

此外，IBM Garage 事件驱动参考架构有一章专门介绍 DDD 方法。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

至于 DDD 的意义，可以说时至今日，它确实非常有效。说完了最新的情况，让我们继续探讨 “为什么？”和 “是什么？”文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

为什么会有 DDD

为什么会需要像 DDD 这样的东西？Eric Evans 在其著作的副标题中提供了一条很好的线索：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

攻克软件核心的复杂性文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

通常情况下，软件项目的主要复杂性在于领域本身。你无法改变领域的复杂性。你可以试试告诉你的银行客户，你将专注于支付，而放弃贷款业务，因为它太复杂了。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

此外，我们不是为了开发软件而开发软件。我们是为了解决问题以及做些改进：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

软件的核心是为用户解决领域相关问题的能力。其他所有功能，虽然也很重要，但都是服务于这一基本目的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

DDD 是什么

微服务的关键特征之一就是其松散的耦合，而这一特征则允许它们单独进行开发、部署、访问控制和扩展。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

那么 DDD 是什么？DDD 无法用一两个句子定义。它是一种开发解决多个问题的复杂软件的方法：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

关注领域的核心复杂性和机会；
领域专家和软件专家合作探索模型；
在有界上下文中说一种通用语言。

（注意正文中的绿色词汇。这些是 DDD 中特有的术语，我会给它们下个定义，就像给领域下定义一样。）文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

这三点是对 DDD 非常高度的概括。接下来，我会一个一个地介绍。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

关注领域

关注领域的核心复杂性和机会。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

这一点我就不过多介绍了。根本的东西我在上面“为什么”这一部分里都已经说明了。软件是没有自我目的的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

不要把这点和“关注业务”弄混了。核心复杂性和机会与我们所说的“业务”并不是一回事。想一下 Twitter。在它的功能中，互相关注等功能并非主要的复杂性所在。主要的复杂性更多的可能还是来自扩展平台。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

探索模型

领域专家和软件专家合作探究模型。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

模型是应对上述复杂性的一种方法。但首先，我们要弄清楚模型是什么？文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

在 DDD 上下文中，模型是什么？文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

描述领域部分方面的一系列抽象，可以用于解决与该领域相关的问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

另一种来自 Eric Evans 的描述：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

模型是一种简化。它是对现实的解释，它将有助于解决现有问题的重要方面抽象出来，而忽略掉不相干的细节。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

我觉得有必要明确下它不是什么：它不是一张图（因此也不是实体关系图（ERD），虽然 DDD 也使用实体这个术语）。图只是帮我们就模型进行交流。在 DDD 的语境下，你会看到许多图。没有什么唯一的建模专用语言。最常用的是一些类似 UML 的图，或者仅仅是一幅手绘草图。重要的不是图，而是图背后的概念。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

选择“探索（explore）”而不是像“写下”这样的词，是有其用意的。要获得一个模型，需要经过一个迭代过程。建模这样的事不可能一次性完成。领域里会有新的洞察，新的或变化的问题，诸如此类。这是一个持续探索的过程。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

模型举例文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

考虑下平常的世界地图（有点像一张图）。标准世界地图显示的是墨卡托投影。人们都知道，地图不是为了说明不同国家的大小或其他类似的东西。它是专门为海上航行而制作的。在地图上的两点之间画一条线，借助指南针就可以知道如何航行了。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

下图显示了地图背后的东西，即具体的模型：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

Eric Evans 在 2019 年的会议演讲中使用的这个例子很不错。它说明了模型与当前的问题直接相关。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

有个模型并不能让你获得任何优势。优势并非因为有模型。优势是你因为有一个模型，可以非常好的匹配你正在设法解决的一组特定问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

对比开头的句子，这里少了一个非常重要的部分：“领域专家和软件专家合作“。模型必须合作探索。不是单由领域专家创建模型，也不是单由开发人员拿 ERD 当模型叫卖。Eric Evans 将合作探索模型的过程称为“知识研磨（Knowledge Crunching）”。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

在本节的最后，让我们看一个非常重要的观点。Eric Evans 的下面两段话是这一观点的最佳表述。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

本书的主旨是，实施、设计和团队沟通应该在一个模型里。不同的用途采用不同的模型会存在隐患。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html
如果编写代码的人觉得自己不负责模型，或者不理解如何在应用程序开发中运用模型，那么模型就和软件没关系了。如果开发人员没有意识到修改代码会改变模型，那么他们的重构会弱化而非强化模型。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

本节要点：代码和模型直接相关。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

说一种通用语言

在有界上下文中说一种通用语言。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

在 DDD 上下文中，通用语言指的是什么？文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

一种围绕领域模型构造的语言，供所有团队在有界上下文中使用，将团队的所有活动与软件联系起来。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

还有一个有必要定义的术语是：有界上下文。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

上下文：单词或语句在其中出现的、可以决定其意思的环境。模型的语句只能在上下文中进行理解。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html
有界上下文：对边界（通常是一个子系统或特定团队的工作）的描述，特定模型在其中定义，同时也是模型的适用范围。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

（至此，我们已经介绍了本文所需的所有定义。）文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

值得注意的是，“通用”语言并不是适用于整个系统的通用。它主要是用于代码、口语、图表等方面。这也是为什么要说“在有界上下文内”。该语言将在你明确定义的边界内适用。它定义的不是跨边界（如整个公司）的术语。举例来说，这会让营销或仓储上下文的文章看起来大相径庭，甚至是在仓储上下文的不同部分也是如此。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

（你可能已经注意到，我在每个定义里都加了“在 DDD 上下文中“。这就是原因。)文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

用我自己的话来说：通用语言是特定领域中与模型直接关联的公共语言，在定义好的边界内可以随处使用。“与模型直接关联”是说语言的变化也会直接关系到模型的变化。事实上，模型应该使用领域专家已经在使用的术语创建。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

[...] 语言的更改将被看成是领域模型的更改，团队得相应地更新类图，重命名代码中的类和方法[...]模型是语言的支柱。[...] 在图表、写作，特别是口语中使用同样的语言。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

现在，我们已经清楚了术语的含义，但为什么这很重要呢？关于这一点，书中有这么一段话：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

在一个没有公共语言的项目里，开发人员得给领域专家做翻译。领域专家要在开发人员之间做翻译，同时还要给其他领域专家做翻译。甚至开发人员之间也需要翻译。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

你一定遇到过这样的情况，开发人员不知道领域专家在说什么，或者更糟糕，你觉得自己知道，但他/她说的其实是其他东西。反之亦然。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

对于使用的专门术语，要使团队养成询问其含义的习惯。团队要在所有的沟通活动中不断地练习使用通用语言。如果领域专家正在谈论的、属于某个特定领域的概念在模型中没有体现，那么这个模型可能不完善。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html

通用语言会使得代码与实际的领域更贴合。这不仅是说代码可以体现实际的领域，而且还有许多其他方面的好处。考虑下代码的可维护性。如果后续有开发人员回过头来查看代码，其中使用了领域术语。确实，领域专家了解用到的术语，但那并不是开发人员定义的类名。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26965.html