我们正在尝试在项目中应用域驱动设计。然而，建模工作量巨大，并且在某种程度上，建模似乎与敏捷原则相冲突，因为许多前期设计已经完成。另一方面，实际利益是分散的或相当长期的，而“需求分析/建模开销”感觉是一个尖锐和持续的问题。
所以，问题出现了：域驱动设计的价值是什么？ 有什么短期利益？
除了你的经验（我觉得非常有趣）：是否有无可争议的合乎逻辑的答案？
答案 0 :(得分：14)
我想我会澄清领域驱动设计并不需要进行大量的前期建模 - 它要求的是与领域专家的对话，通过'明智的探测'获得对领域的直观理解的知识使用无所不在的语言，并不断完善上述所有内容。
战术模式（聚合等）的价值不在于让模型完美呈现，而是从构建应用程序开始，这样当你不可避免地意识到在模型中有更好的表达域的方式时，您可以迭代并将您的见解纳入更新的模型。
所以 - 从这个意义上讲，它非常支持敏捷方法。
对此的最佳参考是来源 - Blue Book' by Eric Evans
的“第三部分重构更深入的洞察力”我建议不要试图'瀑布'你的模型，然后'敏捷'你的代码 - '敏捷'这两个，并接受你将重构你的代码，而不仅仅是当你找到一个更优雅的解决方法技术问题，也是当你找到一种更优雅的商业问题建模方式时。
就“无可争议的合理答案”而言 - 说实话，我不确定你会找到一个。 DDD是一种由不同的人应用的方法 - 它不是一种可以分析其大O复杂性的算法。
我的经验是，通过一系列松散相关的服务分散的贫穷模型和业务逻辑的程序难以迭代并将更深入的见解纳入业务需求，因为规则的更改可能会在整个系统中产生无法预料的影响。他们鼓励系统通过将行为填充到从未打算过的地方来满足新要求，并最终进行涉及多层记忆的对话，使用“员工”这个词有时与“学生”的要求有关。和'老师'。
将每个实体的本质集中到一个类中，并将其暴露在意图揭示界面背后的行为，可以有效推理变更的影响，从而实现模型的持续重构 - 无论是理解增长还是需求变化。
从你的评论中，我现在更好地理解你的意图了 - 我误解了你想要说服DDD是值得的问题 - 而是你正在寻找一个论据来向你的团队说服它是值得的！
不幸的是，这更像是一个人际问题，而不是技术问题，因为一旦他们确信他们走的是正确的道路，人们往往不会被论证所说服。
也许如果你有时间，你可以产生一些验收测试和领域模型的概念证明来说明使用你域中的真实概念的方法？然后，您可以展示随着理解的增长，测试和模型的发展变得多么容易，并且理想地展示通过在代码中积极建模域并执行模型而获得的洞察力。我认为，这是关键，因为在我看来，只有积极地做才能获得这样的见解，并且永远不会通过会议室肚脐凝视。
答案 1 :(得分：2)
您是在创建可执行模型还是纸张？如果您在exploratory modeling中创建（验收测试驱动的）可执行模型，则开销几乎为零