是什么让领域驱动设计变得有价值？

Question

我们正在尝试将领域驱动设计应用到我们的项目中。然而，建模工作是巨大的，而且建模似乎与敏捷原则相冲突，因为完成了大量的前期设计。另一方面，实际的好处是分散的，或者是相当长期的，而“需求分析/建模开销”是一个尖锐和持续的问题。

因此，问题来了:是什么让领域驱动的设计有价值？短期的好处是什么？

除了你的经历(我发现这很有趣)：有没有一个无可争辩的、合乎逻辑的答案？

Answer 1

DDD -连续重构

我想我要澄清的是，领域驱动设计并不需要大量的前期建模--它需要的是与领域专家的对话，通过“明智的声音”使用无处不在的语言来获得对领域的直观理解的知识处理，以及对以上所有内容的持续改进。

战术模式(聚合等)的价值不是预先让模型变得完美，而是通过构建应用程序，当您不可避免地意识到有更好的方法在模型中表示域时，您可以迭代并将您的见解合并到更新后的模型中。

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

最好的参考资料是Blue Book' by Eric Evans的源代码-- "Part for Insight“

我建议不要试图‘瀑布’你的模型，然后‘敏捷’你的代码-‘敏捷’两者，并接受你将重构你的代码不仅当你找到一个更优雅的方式来解决技术问题，也当你找到一个更优雅的方式来建模业务问题。

无可争辩的逻辑答案？

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

我的经验是，模型和业务逻辑薄弱的程序分散在松散相关的服务集合中，难以迭代并将更深层次的洞察合并到业务需求中，因为规则的更改可能会在整个系统中产生不可预见的影响。他们鼓励系统通过将行为塞进它从未打算去的地方来满足新的需求，并且你最终会进行涉及多层的对话，记住使用“员工”这个词的代码有时与对“学生”和“教师”的要求有关。

将每个实体的本质集中到一个类中，并在意图揭示接口后面公开它的行为，可以有效地推理更改的影响，从而支持模型的连续重构-无论是随着理解的增长和需求的变化。

编辑-如何追求他人

从您的评论中，我现在更好地理解了您的意图-我误解了您希望被说服的问题，即DDD是值得的-相反，您正在寻找一个论点来向您的团队展示，以说服他们它是值得的！

不幸的是，这更多的是一个人与人之间的问题，而不是一个技术问题，因为一旦人们确信自己走在正确的道路上，他们往往不会被论点说服。

也许，如果您有时间，您可以制作一些验收测试和域模型的概念证明，以使用您的域中的真实概念来说明该方法？然后，您可以展示随着理解的增长，测试和模型可以多么容易地发展，理想情况下，您可以演示通过在代码中主动建模域并练习模型所获得的洞察力。我相信这是关键，因为在我看来，这样的洞察只能通过积极的行动来获得，而不是通过会议室的凝视来获得的。

Answer 2

你是在创建可执行的模型还是纸质文件？如果像在exploratory modeling中那样创建(验收测试驱动的)可执行模型，那么开销几乎为零