DDD 被高估了吗？

本文最初发布于 INNOQ 博客，经原作者授权由 InfoQ 中文站翻译并分享。

领域驱动设计（DDD）最近越来越受欢迎，新出版的图书、会议演讲以及大量培训就是证明。

虽然很长时间以来，我一直都非常推崇这种方法，但最近，一些人对待它的方式让我恼火。

确切地讲，DDD 这种模式语言为许多知道如何做但不知道如何有效沟通协调的开发人员和设计人员提供了明确的语言。

但我生气的是，最近，似乎任何时候，当有人谈论如何设计系统或服务边界，或者只是提到非技术设计时，每个人都感觉不得不引进 DDD 专家——好像他们是唯一可以设计这些东西的超级英雄。这和其他类似的情况一样糟糕，你盲目地应用当前流行的解决方案，仅仅因为它是每个人都在谈论的事情，而不是因为它是这项工作的正确解决方案。

DDD 很棒，但它只是你应该注意的众多工具和技术之一。

在 DDD 的战略维度中，最常用的工具是“有界上下文”的概念——一个给定的模型通常可以，而且应该被细分为更小的单元，每个单元为特定的概念赋予符合它们自己上下文的特定含义。好主意！这（当然）也不是 DDD 的发明：它只是简单的模块化设计，已经被设计大型系统的人们应用了几十年。

这是否意味着有界上下文的概念有问题呢？不，事实上，该模式的目的是为已经存在并证明了其价值的东西命名。我并不是说有界上下文有什么问题，我只是想指出，有些人可能在没有使用或甚至不知道这个特定称谓的情况下做了出色的系统设计。

在战术层面，人们忽略了一个更重要的方面，特别是当他们将 DDD 作为设计入门时。DDD 强调命名的重要性，并建议你在设计中尽量使用一种通用的、普遍存在的语言。但对于系统设计领域，它也使用自己的语言——诸如有界上下文、聚合、实体、值对象等概念。虽然这些都很好，但它们只是一种可行的语言。将一个值对象称为值对象是有价值的，如果这是一个很多人都理解的术语，就会有助于交流。

但是，现有的、常见的 DDD 概念并不是你唯一应该考虑的概念——它们只是设计和架构系统时一些非常常见的特征的范例：提出并识别模式，给它们起个名字，并使用它们来给出系统结构，保证系统统一性。如果在你的架构中，有一种常见的模式，你使用一个 Filter 将请求路由到一个 Handler，或是使用一个由 Agent 处理的概念 Document，那么这类事情可能会多次发生，和服务或存储库在同一层次上，最终变成对你而言更重要的东西。这很好！

我们可以并且应该发明自己的语言，这种思想比许多天真的 DDD 从业者所认为的要重要得多。我相信 DDD 专家对此非常了解，并将任何 DDD 材料视为起点，而不是最终结果。但是，如果你所做的一切都是按照现有的 DDD 标准术语定义，并试图将任何问题都硬塞到现有的结构中，那么你的生活将非常悲惨。

将 DDD 作为工具集的一部分，但要确保你不会止步于此。有一种生活超越了 DDD。并不是每一个好的设计都需要领域驱动（尽管我认可它应该总是由领域驱动的，只是不一定是 DDD 意义上的）。即使你不是 DDD 专家，也可以设计出好的系统。