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（即差的代码）来支持讲道。
