DDD是浪费时间吗？

Question

谷歌搜索“DDD适合哪种应用？”给了我以下答案：

  

可能95％的软件应用程序属于“使用DDD不太好”的类别。 （见the article）

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

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

Answer 1

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

DDD并不是要编写代码，它不是一个完成软件的关键十步流程，它是关于代码编写之前的整个过程，它是关于深入了解问题的全部内容，是什么/谁参与哪些信息流以及这些元素的外观，它们如何与彼此等相关等等。事实上，DDD最重要的部分是创建一种语言，使域专家和开发人员之间的对话成为可能没有误解。这是埃文斯谈论的“无所不在的语言”。它实际上使得整个过程在代码编写过程之前几乎没有被猜到，事情是清晰和直接的。 （这是目标）。

“DDD如何在实践中发挥作用”和“有人能给我一个如何用DDD编写代码的例子”的问题吗？事实上，人们提出这类问题的重点是编写代码，但不知道他们为什么编写代码而不是其他代码。 I.o.w。：如果你意识到DDD是关于发现什么你要写作功能和为什么，事情就会到位。你是如何编写代码的，这取决于你。但正如所说：那不再是最大的问题，因为你已经知道你要写什么以及为什么。

Answer 2

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

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

Answer 3

很抱歉，如果DDD只是Frans Bouma所说的一种思考方式，那么它就不会推荐Persistence Ignorance这样的东西。这使得其他人成为有点下层阶级的开发人员。

PI，DDD至少有偏见，是一种架构选择。这不是一种思考方式;它已经为你服务了，大部分时间都是含糊不清的警告：“不适合一切”。

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

在整个地方获取一个类似MS Access的界面的ERP软件包：具有运行总计的网格，自动更新列和100000条记录的无页面滚动。显然，DDD方法适合考虑如何使用此应用程序。但是多年来我从来没有见过任何人 - 无论是在书本还是在线，通过证据支持的解释，更不用说现实代码示例，了解PI如何处理这种无处不在的情况，对于任何想要传递的人来说强大的>商业级应用和用户体验。

不想对此有所了解。 DDD和DAL的支持者往往过于虔诚，可能会驱逐那些曾经被咬过但却心胸开阔的人。许多人只是想要面对现实生活中的体验（即思考），而不是只使用猫，汽车和基本的秩序/订单项目（即可怜的CODE）来支持讲道。

Answer 4

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

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

Answer 5

DDD是关于将保持一段时间的软件。对我而言，这意味着它需要表达随域变化的想法。当然，简单的应用程序可能是完美的短交货时间和短的实施时间。但是，如果您需要增加软件，那么DDD原则将会有很大帮助。 DDD可能很难预先考虑，但是一旦你了解了无处不在的语言和分离问题，那么事情就会变得容易。

Answer 6

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

  

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

这就是关于它的大惊小怪的原因。

Answer 7

• 由于您的应用主要以数据为中心，因此您的架构可能主要是传统的。

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

• 一般来说，“声音替代”是让事情尽可能简单，在有用的地方使用DDD概念，并且不要像文章所建议的那样使事情变得不必要。

我现在开始一个类似的项目，它是数据操作和更多逻辑/算法驱动区域的混合。我同样喜欢采用有利于项目的DDD部分，但不要试图在可能适得其反的地方强制使用它。