Googling“DDD适合什么样的应用程序？给我以下答案：
Probably 95% of all software applications fall into the “not so good for using DDD” categories. (see 07000)
那么什么是所有的大惊小怪？
我工作的应用程序主要是以数据为中心，但仍包含一些要应用的业务逻辑和规则。开始使用DDD技术会浪费时间吗？我最好使用更传统的数据访问层，POCOs模型和业务逻辑层？或者说不同 – 什么是DDD的合理替代品？
许多开发人员认为DDD对他们的项目很有用，陷入了他们认为他们的工作是关于编写代码的陷阱。这不是这样的。开发人员的工作是实现功能，以便通过软件解决问题。这导致的结论是，编写代码不是开发人员做什么的开始，但结束：代码是整个过程的结果，在代码实际写入之前。
原文链接：https://www.f2er.com/javaschema/282694.htmlDDD不是编写代码，它不是一个十步的十步流程来获得伟大的软件，它是关于整个过程在代码写之前，它是关于什么问题是什么，什么/谁参与的洞察其中信息流和这些元素是什么样的，它们如何与相互关联等。事实上，DDD的最重要的部分是创建一种语言，使领域专家和开发人员之间的对话可能没有误解。这是Evans谈论的“无所不在的语言”。它实际上使整个过程在代码之前写一个过程，几乎没有被猜到，事情是清楚和直接的。 (这是目标)。
“DDD如何在实践中工作”的问题和“任何人都可以给我一个例子，我如何使用DDD编写代码？和类似的是真正来自这样的事实，人们要求这些类型的问题集中在编写代码，但不知道为什么他们正在编写的代码，而不是其他代码。如果你意识到DDD关于发现你必须写作功能和为什么，事情落到位。你如何编写代码，这取决于你。但正如所说：这不是最大的问题了，因为你已经知道你必须写什么，为什么。
