Oop DDD是浪费时间吗？

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

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

那么，这到底是怎么回事

---

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

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

---

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

这里有一个非常类似的问题：

---

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

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

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

DDD不是关于编写代码，它不是一个获得优秀软件的关键的10步过程，它是关于编写代码之前的整个过程，它是关于了解问题的症结所在，什么/谁参与了哪些信息流，这些元素是什么样子，事实上，DDD最重要的部分是创建一种语言，使领域专家和开发人员之间的对话能够避免误解。这就是埃文斯所说的“无处不在的语言”。实际上，它使代码编写之前的整个过程成为一个几乎不需要猜测的过程，事情变得清晰明了。（这就是目标）

---

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

如果你再多读一点这篇文章，你会看到：

对于5%的应用程序，DDD 非常合身，非常合身。 对于这些情况，DDD将有所帮助 你是个很难对付的人。给你，DDD 也许是解决这个问题的灵丹妙药 狼人，你的经理刚刚 指着你的桌子

这就是为什么人们对它大惊小怪。

• 由于您的应用程序主要以数据为中心，因此您的体系结构可能主要是传统的

• 对于具有更多逻辑和潜在域或值对象的方面，也许可以利用一些DDD思想来组织代码

• 总的来说，“合理的替代方案”是尽可能简单，在有用的地方使用DDD概念，并且不要像文章建议的那样不必要地使事情复杂化

---

我现在开始一个类似的项目，它是数据操作和更多逻辑/算法驱动领域的混合。同样，我也愿意接受DDD中对项目有益的部分，但不要试图将其强加在可能产生反效果的领域。

对不起，如果DDD只是Frans Bouma所说的一种思维方式，那么它就不会推荐诸如坚持无知之类的东西。这就把其他人视为有点低级的开发人员

PI是一种体系结构选择，DDD至少有一个偏差。它不再是一种思维方式；它已经在向你提供一些东西，大多数时候警告过于模糊，没有任何用处：“不适合所有东西”

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

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

---

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

同意-小项目可能不需要所有东西-事实上，一些小项目可能需要比其他项目不同的东西。嗯，mu项目的规模相当大