DDD 语境中什么是领域？

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

我将向您提供 DDD 的概述。这篇文章是关于**DDD 的 “为什么？**我不会深入探讨这里的特定主题。不过，我会指出一些重要术语的定义，就像我刚才对"域"所做的那样。正如您将意识到共享词汇也是 DDD 本身的一部分。

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

DDD 今天的相关性

DDD 不是关于某种技术，它是一个概念。更现代的概念直接指 DDD 。山姆 · 纽曼的《建筑微服务》一书第一页的快速引文：

Eric Evan 的书 DDD 帮助我们理解在我们的代码中代表现实世界的重要性。并给我们展示了更好的方法来建模我们的系统。

此外，IBM 车库事件驱动参考架构有关于方法 DDD 的一章。

回答有关相关性的问题：它确实非常有效，直到今天。随着最新的方式，让我们继续前进，探索"为什么？

为什么 DDD 存在？

为什么甚至需要像 Ddd 这样的东西？埃里克 · 埃文斯书的副标题提供了一个很好的提示：

解决软件核心的复杂性问题

通常，软件项目的关键复杂性在于域名本身。您无法更改域内的复杂性。你可以试着告诉你在银行业的客户，你会专注于支付和放弃贷款业务，因为它太复杂了。

此外，我们开发软件的目的并不只是为了开发软件。我们这样做是为了解决问题和改善现状：

软件的核心是它为用户解决域相关问题的能力。所有其他功能，虽然可能至关重要，但都支持这一基本目的。

DDD 是关于什么的？

那么， DDD 到底是什么？DDD 不能用一两句话来定义。它是开发由多个谜题组成的复杂软件的方法：

1. 关注该领域的核心复杂性和机会。
2. 在域专家和软件专家的协作下探索模型。
3. 在有界限的语境中说一种无处不在的语言。

（注意意用词。这些是 DDD 中的特定术语，我会像使用"域"一词一样定义它们。

这三点已经是 DDD 的一个非常高级别的总结， 但我会在以下部分逐一通过它们。

关注领域

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

我可以保持这个短。它本质上是关于我已经在上面的"为什么？“章节中指出的事情。软件不是出于自我目的。

不要把这和"专注于业务"混为一解。核心的复杂性和机会可能不同于我们所说的"业务”。想想推特吧提供推文的功能、相互关注等并不是主要的复杂性。最有可能的主要复杂性更多的是缩放该平台。

探索模型

在域专家和软件专家的协作下探索模型。

模型是处理上述复杂性的一种方式。但是，首先，什么是模型呢？

i️ DDD 中什么是模型？

描述域选定方面的****抽象系统，可用于解决与该域有关的问题。

描述这个词的另一种方式 （也来自埃里克 · 埃文斯本人）：

模型是一种简化。它是对现实的解释，抽象了与解决手头问题相关的方面，而忽略了无关的细节。

我认为，明确指出它不是值得的：它不是一个图表（因此也不是一个实体关系图（ERD） - 即使实体也是在 DDD 中使用的术语）。图表只是帮助传达模型。在 DDD 的上下文中，您将看到很多图表。没有具体的、唯一的建模语言。通常使用一些类似 UML 的图表或只是手写草图。这不是关于图表，而是关于它背后的概念。

动词"探索"是故意选择的，而不是"写下来"之类的东西。这将是一个迭次的过程，以获得一个模型。没有一劳永逸地完成模型。领域或任何领域都会有新的见解、新的或不断变化的问题。这是一个正在进行的探索。

---

游览：模型示例

想想一个典型的世界地图*（有点像图表）。*世界标准地图显示了墨卡托投影。你们大多数人会知道，这张地图不是关于不同国家的大小或类似的东西。它是专门为海上航行而制作的。您可以在地图上的点之间画一条线，并知道如何使用指南针导航。

这就是地图背后的实际模型：

埃里克·埃文斯在2019年会议演讲中使用的这个例子是一个很好的例子。它指出，该模型与手头的问题直接相关。

---

拥有模型实际上不会给你任何优势。优势不在于有模型。优点来自有一个模型，是一个非常适合一组特定的问题，你正在努力解决。

开句缺少一个关键部分：“域专家和软件专家的合作”。该模型必须通过协作进行探索。无论是域名专家创建模型，还是开发人员出售他们的 ERD 作为模型。埃里克·埃文斯称之为"知识紧缩”，这是共同探索该模型的过程。

结束这一节的最后，非常重要的一点最好通过埃里克·埃文斯的两个报价表达：

本书的主旨是，一个模型应强调实现、设计和团队沟通。为这些单独目的提供单独的模型会带来危险。

如果编写代码的人觉得对模型不负责任，或者不知道如何使模型适用于应用程序，则模型与软件无关。如果开发人员没有意识到更改代码会更改模型，那么他们的重构将削弱模型而不是加强模型。

这些要点：代码和模型是直接相关的。

说无处不在的语言

在有界限的语境中说一种无处不在的语言。

i️在 DDD 中无处不在的语言是什么意思？

围绕域模型构建的语言，所有团队成员在****有限制的上下文中使用该语言将团队的所有活动与软件连接起来。

i️ 还有一个术语值得定义：边界上下文

上下文： 决定其含义的单词或语句的设置。有关模型的陈述只能在上下文中理解。

边界上下文： 定义和适用特定模型的边界（通常是子系统或特定团队的工作）的描述。

（现在我们有这篇文章的所有定义的方式 - 我保证。

值得注意的是，“无处不在"的语言在全系统适用的意义上并不普遍。而是在代码、语音、图表等中使用。这也是为什么"在有限制的范围内"添加限制的原因。该语言将适用于您必须明确定义的边界内。它不是要定义跨越边界的条款，例如整个公司。例如，在营销或仓库环境中，甚至在仓库上下文的不同部分，类似文章的内容可能非常不同。

（也许你已经意识到我在定义中添加了 “在 Ddd 的背景下” 。这正是原因。

用我自己的话说：无处不在的语言是一种与给定域模型直接关联的共同语言，在定义的边界内随处可见。“与模型直接互连"的部分揭示了语言的更改也应与更改模型直接相关。事实上，该模型应该使用域专家已经使用的术语创建。

[…]对语言的更改将被识别为域模型的变化，并将引导团队更新类图，并在代码中重命名类和方法 […]使用模型作为语言的骨干。[…]在图表、写作，尤其是语音中使用相同的语言。

太好了，现在我们知道这个词是什么意思了，但是为什么这很重要呢？本书的这一部分给出了一个原因：

在没有通用语言的项目中，开发人员必须为域专家翻译。域名专家在开发人员和其他域专家之间进行翻译。开发人员甚至相互翻译。

我敢打赌，你遇到了这样的情况：你作为开发人员不知道域专家在说什么，甚至更糟的是，你以为你知道，但他/她在谈论别的事情。情况也是如此。

使团队中要求使用特定术语的含义成为一种习惯。无处不在的语言必须由团队在所有沟通中无情地练习。域专家正在谈论一个未反映在模型中的给定域的概念？模型可能不完整。

无处不在的语言将导致代码和实际域移动更紧密地在一起。它不仅涉及反映实际域的代码，还具有许多其他积极方面。考虑代码的可维护性。如果另一个开发人员在一段时间后返回到代码，则域中将使用术语。域名专家确实了解所使用的术语，它们不仅仅是由开发人员组成的名称的类。

还有更多

这是对DDD的相当高级别的介绍。当然，还有更多。

此图像提供了 DDD 中不同概念的概述。正如你所看到的，我只写了一小部分。我会写一个关于实体、价值对象和聚合物等概念的后续帖子。但这篇文章应该足以了解 Ddd 是什么。

结论

DDD 仍然是工具带中的重要概念。它已经影响了很多其他领域*（看看JPA规范的JavaDoc），*并且仍然影响着它们。

解决域名问题就是开发软件的意义。我们必须处理这种复杂性。但是，通过应用 DDD 来处理这种复杂性，我们可以使我们的生活更轻松。