DDD是浪费时间吗?

谷歌search“DDD适合什么样的应用程序?” 给了我下面的答案:

所有软件应用程序的95%可能属于“不太适合使用DDD”类别。 (见文章 )

那么,什么是大惊小怪?

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

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

DDD不是编写代码,而是编写优秀软件的十个关键步骤,它是关于编写代码之前的整个过程,是要深入了解问题是什么,参与者是什么在哪些信息stream中,这些元素是什么样子,它们是如何相互关联的等等。实际上,DDD最重要的部分是创build一种语言,使得领域专家和开发者之间的对话成为可能而不会被误解 。 这是埃文斯谈到的“无处不在的语言”。 它实际上是在整个过程之前,代码被写成一个没有太多猜测的过程,事情是清楚而直截了当的。 (这是目标)。

“DDD如何在实践中工作”和“谁能给我一个如何用DDD编写代码的例子?”的问题。 这种问题真的来自这样一个事实,即提出这样的问题的人关注于编写代码,但不知道他们为什么要写这些代码而不是其他代码。 Iow:如果你意识到DDD关于发现你要写作的function,那么事情就会落实到位。 如何编写代码,这取决于你。 但是如上所述:这不是最大的问题,因为你已经知道你要写什么,为什么。

这里有一个非常类似的问题: 您是否允许Web层直接访问DAL?

我所有的项目都使用DDD。 在较小的应用程序中,某些概念不适用,但是我发现许多方面都适用于所有项目,而不pipe大小。

DDD是关于将被维护一段时间的软件。 对我来说,这意味着它需要expression的思想,将随着领域的变化。 确定一个简单的应用程序可能是完美的短交货时间和短实施时间。 但是,如果您需要增加软件,那么DDD原则将非常有帮助。 DDD在前面可能很难,但是一旦你了解到无所不在的语言和分离的问题,事情就变得简单了。

如果你再看一篇文章,你会看到:

对于DDD适合的5%的应用来说,这是非常合适的。 对于这些情况,DDD将帮助你破解一个非常艰难的坚果。 在这里,DDD可能是你的经理指出你的办公桌的狼人的银弹。

这就是为什么大惊小怪。

  • 由于你的应用程序主要是以数据为中心的,所以你的架构可能主要是传统的。

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

  • 一般来说,“合理的select”是要尽可能简单,在有用的地方使用DDD概念,不要使事情复杂化,正如文章所build议的那样。

我现在正在开始一个类似的项目,它是一个混合的数据操作和更多的逻辑/algorithm驱动的领域。 我也同样喜欢采取DDD的部分,这将有利于该项目,但不要试图强迫它可能会适得其反的地区。

你知道,有时候5%比95%赚得更多 – 这就是DDD存在的原因。

它是针对特定复杂的大型系统。

对不起,如果DDD只是Frans Bouma所说的一种思维方式,那么就不会推荐持久性无知之类的东西。 这是把其他人视为有些底层的开发者。

PI对于DDD至less有一个偏见,是一个build筑select。 这不是一种思维方式; 它已经是你的东西了,大部分时间太模糊的警告是有用的:“不适合所有的东西”。

但决定采用PI方式本身就是一个挑战,如果对这个问题感到不安,就不能称呼某人(“编码员”)。

把一个ERP软件包带到一个类似MS Access的界面:带有运行总数的网格,自动更新列和100000条logging上的无页面滚动。 显然,DDD方法适合考虑如何去使用这个应用程序。 但多年以来,我从来没有见过任何人 – 无论是在书本还是在线上,都没有看到证据支持的解释,更不用说现实生活中的代码示例,PI如何处理这种无处不在的情况,希望提供商业级应用程序和用户体验

不想在这方面得到宗教信仰。 DDD和DAL的支持者往往过于虔诚,可能会驱走那些曾经被咬过,但是开放的人。 许多人只是想要面对现实生活中的经验(即THINK),而不能得到猫,汽车和基本的Order / OrdersItems(即差的代码)来支持讲道。