面向所有人的领域驱动设计

最近，无论是在聚会上还是与客户，我一直在谈论领域驱动设计（DDD），所以我想写下我的想法，看看是否有帮助。

现在，很多人都从技术角度撰写了有关 DDD 的文章（请参阅最后的链接），所以我不会这样做，而是从非技术角度讨论 DDD。

对于其他人来说，这就是 DDD。

解决方案总是超出预期

设计和构建解决方案并非易事。它绝非一帆风顺，即使按时完成（这从来都不可能），解决方案通常也缺乏效率，需要进行修改，而且往往需要进行彻底的修改。这会导致更多的延误、更大的预算，甚至最终带来更大的问题。

为什么这种情况不断发生？

复杂与复杂

建立一个盈利的企业是一个复杂的问题，复杂不同于复杂。

比如，“税收”就很复杂。其中有许许多多错综复杂的规则和流程，但一旦你知道如何运用它们（流程），问题就迎刃而解了。它变成了程序化的流程，无需任何思考。只要遵循流程，就万事大吉了。

创业根本不是那样，有太多未知数。换句话说，它很复杂。仔细想想，这一点显而易见。如果存在这样的流程，那么每个人都会照搬。风险为零（这样就不需要写这篇文章了）。

复杂问题无法控制，只能管理。然而，我们仍然试图将业务发展视为一个过程，因为我们真心希望它成为一个过程。看看“敏捷”*和“精益”的流行，尤其是那些被大力推广、以流程为导向的版本，它们再次强化了这种错觉（而且它们也行不通）。这不过是痴心妄想。

DDD 承认这一事实，它不再专注于僵化的流程和硬性规则（即一刀切的解决方案），而是提供了管理和消除歧义的技术。秘诀不在于遵循流程，而在于不断迭代你试图解决的问题。

关注（正确的）问题

在领域驱动设计 (DDD) 中，领域（即问题及其产生的知识/活动）是其他一切的驱动力。所有解决方案都源于问题，因此将核心领域置于中心位置自然会带来更好的解决方案。

比如说，假设你的业务是在线新闻。你的“核心”领域（也就是驱动你业务的领域）是内容生成，其他一切都是次要的。通过更快地制作更好的内容，你的业务将会增长。然而，如果你专注于解决图像大小调整的问题（并雇佣大量开发人员来编写软件），那么你的业务很可能无法增长。

DDD 带来清晰度，通过清晰度，我们能够集中注意力。

与专家交谈

如果你想理解一个问题，那么你需要与领域专家交流。领域专家比任何人都更了解这个问题，他们能够告诉你什么是重要的，什么是不重要的。

在大多数组织中，领域专家并非解决方案的构建者。DDD 有助于弥合领域专家的知识与解决方案构建者试图理解的知识之间的差距。

这就是为什么很多 DDD 技术与技术无关，而是专注于人以及挖掘复杂性和模糊性的方法。如果我们都达成共识，前进就更容易。

建立共识

获得清晰思路的一个关键方法是建立对问题的共同理解，即领域模型。如果每个人心中都有相同的模型，那么就不会产生歧义。这有助于我们避免解决方案过于复杂，或者更糟的是，构建错误的解决方案（例如上面的图像调整器）。

你说得对，是吗？

语言是 DDD 的核心。我们使用语言来表达想法、探索问题并定义解决方案。如果领域很复杂，那么语言也会变得丰富而复杂，并具有其自身的微妙之处和细微差别。

问题是，你公司里的大多数人可能并不认同这种语言。他们用自己的语言来解决问题，这很正常。然而，当两个或两个以上的人试图用不同的语言进行交流却不自觉时，就会出现问题，例如，相同的词语含义不同。这会导致歧义，并成为错误和误解的主要原因。

人越多，问题就越严重。以典型的指挥链为例。

这很容易导致沟通不畅。如果你曾经请求过某个功能，结果得到的回复却与你的预期相差甚远，原因就在于此。

解决方案是每个人都与领域专家紧密合作，理解业务定义的语言，并找出这些语言界限的存在，例如，一个词在不同语境中的使用情况。这使得每个人都能进行沟通（即拥有共享的领域模型），从而减少孤岛现象，促进协作，并简化解决方案。

您的解决方案反映了您对问题的理解

你构建的任何解决方案都直接反映了你对问题的理解程度。如果解决方案好，说明你理解了你的领域；如果解决方案不好，说明你不理解。这就是为什么快速迭代如此重要，它关乎加强反馈循环并针对问题进行迭代，而不是第一次尝试就构建出正确的解决方案（这种情况永远不会发生）。

通过将你的解决方案作为反馈，你可以进行进一步的讨论，并确定是否接近目标，从而构建更好的领域模型，最终产生新的解决方案，并反馈到你对问题的理解。这是一个循环，它鼓励我们更好地理解我们正在做的事情，而不是把解决方案视为一切。

更快的反馈就是更好的反馈

解决方案测试得越快越好。这并不意味着你需要构建软件，因为构建软件是最昂贵的测试方式。为什么不直接用模型，甚至纸笔来制作解决方案的原型呢？你只需花费一小部分时间就能获得同样的反馈。领域驱动设计 (DDD) 鼓励提前发现和迭代，而不是为了编写软件而编写。

这并不是说 DDD 很少讨论软件，它确实讨论过，而且有很多编写软件的模式，但软件并非核心。DDD 中有一句俗语：最好的软件就是没有软件。你看，软件会增加复杂性，所以如果可以避免这种复杂性，就应该避免。优秀的 DDD 从业者会尝试寻找现有的问题解决方案，只有在定制软件能够带来最大价值的情况下才会考虑使用。

自我提升

DDD 关注的是理解问题并不断迭代。这是循环的，这意味着 DDD 经常被用来理解自身并不断改进。你可以想象这个反馈循环有多快，而且 DDD 从业者总是在迭代、发现和命名模式和技术。随着时间的推移，它只会越来越好。

结论

简而言之，DDD 将业务及其领域置于其应有的主导地位。我已经使用 DDD 五年了，不得不说，我构建实用解决方案的能力得到了极大的提升。它帮助我磨练了理解和迭代问题所需的技术和技能。如果你想在构建解决方案方面更上一层楼，我诚挚地推荐 DDD。

进一步阅读

附言：
*这是对大写字母“Agile”的挖苦，这是顾问们推销的一种解决所有开发问题的单一方法，而不是真正的“敏捷”。这很好，因为它专注于迭代编写软件的问题，适应变化。

文章来源：https://dev.to/barryosull/domain-driven-design-for-everyone-else-a9