领域驱动设计的价值在哪里？

Question

我们正在尝试将领域驱动设计应用于我们的项目。然而，建模工作量巨大，有些建模似乎与敏捷原则相冲突，因为需要做很多前期设计。另一方面，实际的好处比较难以量化或者是更加长期的，而“需求分析/建模开销”的问题是一个严重而持续的问题。

那么问题来了: 什么让领域驱动设计值得去做呢？有哪些短期的好处呢？

除了你的经验（我觉得非常有趣），是否还有一个不容置疑的、逻辑上的答案呢？

- Sir Hackalot

Answer 1

DDD - 持续重构

我想澄清一下，领域驱动设计并不需要大量的前期建模。它需要与领域专家进行交流，通过“合理听起来”的通用语言来获得对领域的直观理解，并持续完善所有内容。

战术模式（聚合等）的价值并不在于完美地建立模型，而在于构建应用程序的结构，使您可以迭代并将有关领域模型的见解纳入更新后的模型中。

因此，在这个意义上，它高度支持敏捷方法。

最好的参考资料是源代码 - Eric Evans 的《Blue Book》第 III 部分“向更深层次洞察重构”。

我建议不要尝试“瀑布”式地建立模型，然后“敏捷”地编写代码 - 两者都要“敏捷”，并接受您不仅在找到更优雅的解决技术问题的方法时重构代码，而且在找到更优雅的建模业务问题的方法时也要重构。

无可争议的逻辑答案？

说到“无可争议的逻辑答案” - 老实说，我不确定你能找到一个。DDD是一种不同人应用不同的方法 - 它不是可以分析其大O复杂度的算法。

我的经验是，具有贫血模型和业务逻辑散布在一堆松散相关服务中的程序很难迭代并将更深入的业务需求纳入其中，因为规则的更改可能会在整个系统中产生不可预见的影响。它们鼓励新要求通过将行为塞入从未打算去过的地方来满足，并且最终您会进行涉及多层记忆的对话，即使用“员工”一词的代码有时与“学生”和“老师”的要求相关。

将每个实体的本质集中到一个类中，并通过意图显示的接口公开其行为，可以有效地推理出变化的影响，从而使模型能够持续重构 - 随着理解的增长和需求的变化。

编辑 - 如何说服他人

从您的评论中，我现在更好地理解了您的意图 - 我误解了您正在寻找被说服DDD是值得的 - 而您正在寻找一个论点来向您的团队提出说服他们这是值得的！

很不幸，这更多是一个人际问题而非技术问题，因为一旦人们确信自己走在正确的道路上，他们通常不会被论据所说服。

也许如果您有时间，您可以制作一些验收测试和领域模型的概念证明，以实际概念为例说明使用方法？然后您可以展示如何轻松地随着理解的增长来发展测试和模型，并理想地演示通过在代码中积极建模并运用模型获得的洞察力。我认为这很关键，因为在我的看法中，只有通过积极实践才能获得这样的洞察力，并且永远不会通过开会讨论来实现这一点。

- Chris Simon

---

我还建议，如果最初的建模工作证明很繁琐 - 重新审视战略模式和边界上下文的分解。大多数系统都可以分解成不超过10个模型的有界上下文 - 进一步简化该上下文需求的分析应该是可能的。 - Chris Simon

谢谢Chris。我完全同意DDD不需要预先建模，也不需要精确的规范。我知道DDD与敏捷开发很搭配。然而，我的团队正在专注于技术方面，开发人员非常快地生产出产品，但并没有讨论领域知识。所以，现在是技术驱动的设计。总的感觉是“我们没有时间做所有的交流和知识碾磨”（至少从我的角度来看是这样）。因此，我想说：“看，如果你使用DDD，你目前正在处理的任务会变得更容易”，或者其他类似支持性的话语。 - Sir Hackalot

编辑后添加了一些说服他人的建议。 - Chris Simon

Answer 2

你是在创造可执行的模型还是纸质模型？如果你像在探索性建模中一样创建（验收测试驱动的）可执行模型，那么开销基本上为零。

- Stephan Eggermont

---

谢谢 Stephan。探索性建模听起来非常完美。目前有可执行的线框图和上下文场景。我正试图建立出色的验收测试，因为我在其他项目中的经验告诉我，它们是领域建模和其他事情的良好基础。然而，领域专家不愿编写绑定测试，因为他们担心会错过重要的事情。他们想在自己那边进一步讨论这些问题，这感觉很像“前期设计”。不确定如何说服他们跳入深水区并编写这些测试等等。他们能从中得到什么？ - Sir Hackalot

也许告诉他们绑定测试的目标不是完整性，而是限制解决方案会有所帮助。添加更多测试可以使解决方案越来越接近。棘手的部分是尽可能少地过度和欠约束。 - Stephan Eggermont