领域驱动设计入门

https://blog.jannikwempe.com/domain-driven-design-introduction

作者 | Jannik Wemp

译者 | 平川

策划 | 万佳

领域驱动设计（DDD）是由Eric Evans发明的一个概念。他在2004年出版的《领域驱动设计》一书（即”大蓝皮书“）中探讨了这个概念。我将概要地介绍下DDD的方方面面。本文将探讨DDD“为什么？”和“是什么？”。在这里，我不会深入探讨具体的主题。不过，我会说明重要术语的定义。

领域驱动设计（DDD）是由Eric Evans发明的一个概念。他在2004年出版的《领域驱动设计》一书（即”大蓝皮书“）中探讨了这个概念。

那么在DDD上下文中，领域是什么？

领域是知识、影响或活动的范围。用户应用程序的主题域即软件的领域。

我将概要地介绍下DDD的方方面面。本文将探讨DDD“为什么？”和“是什么？”。在这里，我不会深入探讨具体的主题。不过，我会说明重要术语的定义，就像上面的“领域”。你会发现，共享词汇也是DDD本身的一部分。

首先，你要问自己，这些概念是否仍然有效？

1DDD的意义

DDD不是一种特定的技术，它是一个概念。许多现代概念都直接使用DDD。下面这段话出自Sam Newman《微服务设计》一书的第一页。

Eric Evans的《领域驱动设计》一书帮助我们理解了用代码呈现真实世界的重要性，并且告诉我们如何更好地进行系统建模。

此外，IBM Garage事件驱动参考架构有一章专门介绍DDD方法。

至于DDD的意义，可以说时至今日，它确实非常有效。说完了最新的情况，让我们继续探讨 “为什么？”和 ”是什么？“

2为什么会有DDD

DDD不是一种特定的技术，它是一个概念。许多现代概念都直接使用DDD。下面这段话出自Sam Newman《微服务设计》一书的第一页。

为什么会需要像DDD这样的东西？Eric Evans在其著作的副标题中提供了一条很好的线索：

攻克软件核心的复杂性

通常情况下，软件项目的主要复杂性在于领域本身。你无法改变领域的复杂性。你可以试试告诉你的银行客户，你将专注于支付，而放弃贷款业务，因为它太复杂了。

此外，我们不是为了开发软件而开发软件。我们是为了解决问题以及做些改进：

软件的核心是为用户解决领域相关问题的能力。其他所有功能，虽然也很重要，但都是服务于这一基本目的。

3DDD是什么

微服务的关键特征之一就是其松散的耦合，而这一特征则允许它们单独进行开发、部署、访问控制和扩展。

那么DDD是什么？DDD无法用一两个句子定义。它是一种开发解决多个问题的复杂软件的方法：

1. 关注领域的核心复杂性和机会；

2. 领域专家和软件专家合作探索模型；

3. 在有界上下文中说一种通用语言。

（注意正文中的绿色词汇。这些是DDD中特有的术语，我会给它们下个定义，就像给领域下定义一样。）

这三点是对DDD非常高度的概括。接下来，我会一个一个地介绍。

关注领域

关注领域的核心复杂性和机会。

这一点我就不过多介绍了。根本的东西我在上面“为什么”这一部分里都已经说明了。软件是没有自我目的的。

不要把这点和“关注业务”弄混了。核心复杂性和机会与我们所说的“业务”并不是一回事。想一下Twitter。在它的功能中，互相关注等功能并非主要的复杂性所在。主要的复杂性更多的可能还是来自扩展平台。

探索模型

领域专家和软件专家合作探究模型。

模型是应对上述复杂性的一种方法。但首先，我们要弄清楚模型是什么？

在DDD上下文中，模型是什么？

描述领域部分方面的一系列抽象，可以用于解决与该领域相关的问题。

另一种来自Eric Evans的描述：

模型是一种简化。它是对现实的解释，它将有助于解决现有问题的重要方面抽象出来，而忽略掉不相干的细节。

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

选择“探索（explore）”而不是像“写下”这样的词，是有其用意的。要获得一个模型，需要经过一个迭代过程。建模这样的事不可能一次性完成。领域里会有新的洞察，新的或变化的问题，诸如此类。这是一个持续探索的过程。

模型举例

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

下图显示了地图背后的东西，即具体的模型：

Eric Evans在2019年的会议演讲中使用的这个例子很不错。它说明了模型与当前的问题直接相关。

---

有个模型并不能让你获得任何优势。优势并非因为有模型。优势是你因为有一个模型，可以非常好的匹配你正在设法解决的一组特定问题。

对比开头的句子，这里少了一个非常重要的部分：“领域专家和软件专家合作“。模型必须合作探索。不是单由领域专家创建模型，也不是单由开发人员拿ERD当模型叫卖。Eric Evans将合作探索模型的过程称为“知识研磨（Knowledge Crunching）”。

在本节的最后，让我们看一个非常重要的观点。Eric Evans的下面两段话是这一观点的最佳表述。

本书的主旨是，实施、设计和团队沟通应该在一个模型里。不同的用途采用不同的模型会存在隐患。

如果编写代码的人觉得自己不负责模型，或者不理解如何在应用程序开发中运用模型，那么模型就和软件没关系了。如果开发人员没有意识到修改代码会改变模型，那么他们的重构会弱化而非强化模型。

本节要点：代码和模型直接相关。

说一种通用语言

在有界上下文中说一种通用语言。

在DDD上下文中，通用语言指的是什么？

一种围绕领域模型构造的语言，供所有团队在有界上下文中使用，将团队的所有活动与软件联系起来。

还有一个有必要定义的术语是：有界上下文。

上下文：单词或语句在其中出现的、可以决定其意思的环境。模型的语句只能在上下文中进行理解。

有界上下文：对边界（通常是一个子系统或特定团队的工作）的描述，特定模型在其中定义，同时也是模型的适用范围。

（至此，我们已经介绍了本文所需的所有定义。）

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

（你可能已经注意到，我在每个定义里都加了“在DDD上下文中“。这就是原因。)

用我自己的话来说：通用语言是特定领域中与模型直接关联的公共语言，在定义好的边界内可以随处使用。“与模型直接关联”是说语言的变化也会直接关系到模型的变化。事实上，模型应该使用领域专家已经在使用的术语创建。

[...] 语言的更改将被看成是领域模型的更改，团队得相应地更新类图，重命名代码中的类和方法[...]模型是语言的支柱。[...] 在图表、写作，特别是口语中使用同样的语言。

现在，我们已经清楚了术语的含义，但为什么这很重要呢？关于这一点，书中有这么一段话：

在一个没有公共语言的项目里，开发人员得给领域专家做翻译。领域专家要在开发人员之间做翻译，同时还要给其他领域专家做翻译。甚至开发人员之间也需要翻译。

你一定遇到过这样的情况，开发人员不知道领域专家在说什么，或者更糟糕，你觉得自己知道，但他/她说的其实是其他东西。反之亦然。

对于使用的专门术语，要使团队养成询问其含义的习惯。团队要在所有的沟通活动中不断地练习使用通用语言。如果领域专家正在谈论的、属于某个特定领域的概念在模型中没有体现，那么这个模型可能不完善。

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

4更多概念

上面的内容是对DDD一个高度概括的介绍。无疑，它还有许多其他的概念。

上图是DDD中不同概念的一个总览。如你所见，我只介绍了其中的一小部分。我接下来会写一篇文章介绍实体、值对象和聚合的概念。但本文足以帮你了解DDD是干什么的。

5总结

DDD仍然是你工具箱中的一个重要概念。它已经影响了许多其他的领域可以看下JPA规范的JavaDoc：https://github.com/spring-projects/spring-data-jpa/blob/main/src/main/java/org/springframework/data/jpa/domain/Specification.java

并且还会继续影响它们。

解决领域问题是软件开发的全部内容。那是我们需要面对的复杂性。但是，运用DDD可以让我们的工作变得更轻松。

希望您喜欢这篇文章。欢迎反馈。您可以在Twitter或LinkedIn上联系我：https://twitter.com/JannikWempehttps://www.linkedin.com/in/jannik-wempe/

6
相关资料

当然，最主要的资料是《领域驱动设计》一书：https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/

Eric Evans在网上免费提供的领域设计驱动参考：https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf。

IBM Garage事件驱动参考架构也包含有关DDD的信息：https://ibm-cloud-architecture.github.io/refarch-eda/methodology/domain-driven-design

我很喜欢Eric Evans在DDD欧洲2019大会上的这个演讲：https://youtu.be/pMuiVlnGqjk

当然，YouTube上还有其他许多不错的演讲。