DDD是浪费时间吗？ [关闭]答案

【问题标题】：Is DDD a waste of time? [closed]DDD是浪费时间吗？ [关闭]
【发布时间】：2010-10-23 01:48:18
【问题描述】：

谷歌搜索“DDD 适合什么样的应用程序？”给了我以下答案：

大约 95% 的软件应用程序属于“不太适合使用 DDD”类别。（见the article）

那么有什么大惊小怪的？！？

我正在开发的应用程序主要以数据为中心，但仍包含一些要应用的业务逻辑和规则。开始应用 DDD 技术会浪费时间吗？我是否最好使用更传统的数据访问层、POCO 模型和业务逻辑层？或者换一种说法 - DDD 的合理替代方案是什么？

【问题讨论】：

【解决方案1】：

许多认为 DDD 对他们的项目有用的开发人员落入了一个陷阱，他们认为他们的工作就是编写代码。事实并非如此。开发人员的工作是实现功能，以便可以通过软件解决问题。由此得出的结论是，编写代码不是开发人员正在做的事情的开始，而是结束：代码是实际编写代码之前整个过程的结果。

DDD 不是关于编写代码，它不是获得优秀软件的 10 步全包流程，它是关于在编写代码之前的整个过程，它是关于深入了解问题的全部内容，是什么/谁参与了哪些信息流，这些元素是什么样的，它们如何相互关联等等。事实上，DDD 最重要的部分是创建一种语言，使领域专家和开发人员之间的对话成为可能没有误解。这就是埃文斯所说的“无处不在的语言”。它实际上使编写代码之前的整个过程成为一个几乎没有被猜测的过程，事情变得清晰而直接。（这就是目标）。

“DDD 在实践中如何工作”和“谁能给我一个如何使用 DDD 编写代码的示例”的问题？诸如此类的问题确实来自这样一个事实，即提出此类问题的人专注于编写代码，但不知道为什么他们要编写该代码而不是其他代码。 I.o.w.：如果你意识到 DDD 是关于发现你必须写什么作为功能和为什么，那么事情就到位了。你如何编写代码，这取决于你。但正如所说：这不再是最大的问题，因为那时你已经知道你要写什么以及为什么要写。

【讨论】：

这是一种思考方式，而不是一种编写代码的方式。对域的思考推动了您的设计，从而产生了可以是任何东西的代码。有些人错误地在代码中思考，而忘记了思考，即面向领域的设计。
+1 很好地描述了 DDD 的好处。我认为它可以概括为“创建一种语言，使领域专家和开发人员之间的对话成为可能而不会产生误解。”
好吧，Wikipedia 正在以相当以代码为中心的方式定义 DDD，或者至少强调使用某些特定于 DDD 的代码设计模式...
@LuftMensch：是的，你的错误是认为维基百科是权威资源
它是最大的协作纲要之一，任何人都可以编辑它......如果它在那里，它至少意味着大多数/很多人理解某事的方式......实际上大多数人没有不要将 DDD 视为对业务的简单理解——这是我们一直需要做的事情。在实践中，似乎 + 将 DataTables 交换为所有内容的自定义存储对象......以及存储库和工厂来管理和创建这些对象......然后你经常有很多很多这样的对象飞来飞去 - 因此最好仅在真正有用的地方应用这些模式。

【解决方案2】：

抱歉，如果 DDD 只是 Frans Bouma 所说的一种思维方式，那么它不会推荐诸如 Persistence Ignorance 之类的东西。这是在贬低其他人，将其视为有些低级的开发人员。

DDD 至少对它有偏见的 PI 是一种架构选择。这不再是一种思维方式；它已经为您提供了一些东西，但大多数情况下过于模糊的警告没有任何用处：“不适合所有事情”。

但是决定是否采用 PI 方式本身就是一个挑战，如果他对此感到不安，你就不能称呼某人（“程序员”）。

采用一个带有 MS Access 式界面的 ERP 软件包：带有运行总计的网格、自动更新列和 100 000 条记录的无页滚动。显然，DDD 方法适合思考如何开发这个应用程序。但多年来，我从未见过任何人——无论是在书本上还是在网上，都通过证据支持的解释，更不用说现实生活中的代码示例，说明 PI 如何为任何想要交付的人处理这种无处不在的情况商业级应用和用户体验。

不想在这件事上变得虔诚。 DDD 和 DAL 的支持者往往过于虔诚，可能会赶走那些曾经被咬过但思想开放的人。许多人只想面对现实生活中的经历（即思考），而不是仅仅获得猫、汽车和基本的订单/订单项目（即糟糕的代码）来支持讲道。

【讨论】：

我知道.. 我对愚蠢的 Cars 和 OrderLine 示例感到厌烦。 那一刻我进入了一个真正的 ERP 项目，我遇到了一些非常困难的情况，这些情况很常见，但在我读过的所有 DDD 中都没有涉及到。

【解决方案3】：

这是一个非常相似的问题：Do you allow the Web Tier to access the DAL directly?

我的所有项目都使用 DDD。在较小的应用程序中，一些概念并不适用，但我发现许多方面适用于所有项目，无论大小。

【讨论】：

同意 - 较小的项目可能不需要所有东西 - 事实上，一些较小的项目可能需要与其他项目不同的东西。
嗯，mu 项目的规模很大……你认为 DD 以数据为中心时弊大于利吗？

【解决方案4】：

你知道，有时 5% 的人比其他 95% 的人赚的钱更多——这就是 DDD 存在的原因。

适用于特定的复杂大型系统。

【讨论】：

并非总是...“金钱”域是一个受益于 DDD 的相对较小的系统，通常用于在小范围内演示 DDD 的概念。
@JasonTrue：企业系统在概念上与金钱无关。
我只是通过重复“钱”来表现得很可爱，因为我的观点是，有一些小型系统可以从 DDD 中受益，而不仅仅是大型复杂系统。

【解决方案5】：

DDD 是关于将被维护一段时间的软件。对我来说，这意味着它需要表达随领域而变化的想法。当然，一个简单的应用程序可能非常适合较短的交付时间和较短的实施时间。但是，如果您需要发展软件，那么 DDD 原则将大有帮助。 DDD 一开始可能很难，但是一旦您了解了无处不在的语言和分离问题，那么事情就开始变得容易了。

【讨论】：

【解决方案6】：

如果你再阅读这篇文章，你会看到：

对于使用 DDD 的 5% 的应用程序非常合身，非常合身。对于这些情况，DDD 会有所帮助你破解了一个非常坚韧的坚果。在这里，DDD 可能是银弹狼人，你的经理只是指着你的桌子。

这就是为什么大惊小怪的原因。

【讨论】：

您还会看到：“不要指望奇迹出现，并注意不要为了代码而过度复杂化——有时更简单确实更好。”
@Luft Mensch => “简单胜于复杂。复杂胜于复杂。| @fedecarg”

【解决方案7】：

由于您的应用程序主要以数据为中心，因此您的架构可能主要是传统的。
对于你有更多逻辑和潜在领域或价值对象的方面，也许你可以利用 DDD 的一些想法来组织代码。
一般来说，“合理的替代方案”是让事情尽可能简单，在有用的地方使用 DDD 概念，不要让事情变得不必要地复杂化，正如文章所建议的那样。

我现在开始了一个类似的项目，它混合了数据操作和更多的逻辑/算法驱动领域。我同样希望采用 DDD 中有益于项目的部分，但不要试图在可能适得其反的领域强加它。

【讨论】：

DDD 是个噱头，它不会带来任何新想法，它只是纯粹的旧 OOP/OOD，偏向于编码实践的最新发展。 “首先与领域专家交谈，确定关键抽象”是您在任何 30 年前的 OOP 书籍中读到的第一句话。 “将功能封装在域类中，除非它没有意义”...... Duh！