什么是领域驱动设计？

领域驱动设计（DDD）是设计高质量软件的一门学科。有人会称之为应用哲学，因为它带有工具和方法，非常实用。

DDD 的核心承诺是它可以帮助您以更可持续的方式处理复杂性。它有助于创建一个不仅仅是解决当前问题的软件系统。软件系统往往有很多不必要的复杂性。
通过 DDD 专注于领域建模，您可以清楚地了解业务领域固有的复杂性，并消除不必要的复杂性。您最终将得到一个可以快速发展的系统。

与大多数软件设计方法不同，DDD 着眼于整个系统；这是否是在微观层面上的单个代码和设计模式；代码组织、领域、有界上下文和架构方面的更大结构；或超大规模集群和集成。

DDD 由 Eric Evans 创造，并通过他的书“领域驱动设计：2003 年解决软件核心的复杂性”(*) 而流行起来。 DDD 附带了一个模式目录，也就是说，软件设计人员已经在实践的一组连贯的模式。
DDD 命名并解释这些模式。它还带有一些创新，例如限界上下文。领域驱动设计为团队提供了一种新的共享抽象，使讨论软件设计变得更加容易。

DDD 有丰富的原则和模式，所以这里我们只讨论几个核心思想。

 领域建模

为了处理复杂性，DDD 建议创建和发展业务领域的模型。这些模型是与领域专家合作构建的，并用作代码、测试、文档、用户界面和有关领域的对话的基础。
与我们在大多数软件中找到的纯技术模型相比，此类模型的优点在于它们编码并保留了更多有关该领域的知识。
这有助于保持复杂性易于理解和管理，从而使软件的未来发展变得更加容易。

我们可以像科学家思考科学模型一样思考领域模型。以重力为例，它并不完美，但对于日常使用来说已经足够了，知道如果你掉落一个物体，它就会掉落。
还有更先进的模型，例如量子物理学，对于做某些其他事情很有用，但它太复杂了，无法仅仅知道如果你掉落一个玻璃杯，它会掉到地板上并摔成碎片。所以一个伟大的模型是有背景的。
它是问题领域的一组有用的抽象。就像在科学中一样，一个伟大的模型为您提供了可预测性：您可以预测系统将如何运行，以及如何在不破坏系统的情况下改变系统。

自 Eric Evans 出版这本书以来，出现了许多与 DDD 密切相关的有价值的建模技术，包括 EventStorming(**)。

 无处不在的语言

在任何社会群体中，例如团队、部门或公司，语言都会不断发展，以满足该群体的需求。像这样的语言是有机的，总是动态的，但常常是混乱和模糊的。这很正常，这就是自然语言的工作原理。
但当我们进行系统设计时，我们需要语言精确且明确。通用语言是一种基于领域而精心设计的语言，我们可以用它与所有工程和业务利益相关者进行精确的交谈。
我们在代码和其他制品中使用相同的语言，这有助于使我们的系统从长远来看易于理解。
在最好的情况下，通用语言的使用非常好，以至于非技术领域专家可以阅读代码并理解它的作用（并检测错误！）。
但即使没有走那么远，这种共享语言也使软件的沟通更加顺畅，从而使最终的软件更加符合业务需求。

 有界上下文

为了管理复杂性，我们需要将软件及其模型分成更小的单元。传统上，我们使用技术分离，例如组件、模块和（微）服务。

DDD 的做法有所不同：首先查看领域语言和模型，然后围绕它们划定界限。在这些限界上下文中，语言和模型是一致且明确的。
我们不会尝试在整个组织内建立单一的通用模型，因为这行不通，而且协调成本很高。组织成更小的独立模型使我们能够使它们更好地符合业务需求，并让我们不断发展它们以继续满足这些需求。

为其建立直觉的一种方法是，有界上下文是可理解的边界。它将需要理解的概念组合在一起，并将它们与不相关的概念分开。
这是非常高效的，因为新的团队成员可以快速学习一个小的有界上下文，而不必费力地学习不相关的概念。

在实践中，您仍然希望将代码分离到模块或服务中，但是您的分离将更多地受到实际业务领域的启发，而不是技术或组织问题。

 DDD的优点

成熟的 DDD 系统的核心优势是您拥有与您正在解决的问题真正相似的代码和工件。
该代码使用与业务利益相关者相同的语言，并且您的共享模型表达业务概念、行为、规则、流程和关系。
比如说，添加一个新的业务规则变得微不足道：它适合什么地方是显而易见的，而且它会产生什么影响也是可以预测的。

拥有清晰的模型、语言和边界可以让您行动得更快。您不必浪费时间对代码应该执行的操作进行逆向工程，因为它清楚地传达了意图。
人们常常低估使用这些技术响应市场变化和客户需求的速度。

* https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/

** https://www.eventstorming.com/