我经常看到诸如“App x没有足够复杂的域来证明多层体系结构的开销的说法。它更适合于表单而不是数据方法。”我想知道一个领域的特征是什么会迫使人们采用特定的方法。也就是说，你怎么知道什么时候做一些简单的事情，比如表格而不是数据，或者什么时候你应该建立多层，域，DTO等等。
答案 0 :(得分：3)
这绝不是决定性的，但我想说数据上的表单主要指的是业务规则渺茫且轻松的域名。也就是说，如果您只是将数据从屏幕输入到或多或少直接持久化的平面数据结构中，我认为DDD架构并不那么重要。但是，如果您的域名由多个聚合组成，并且/或者业务规则很重，那么您应该考虑DDD。
当然，正如我们世界上的所有事物一样，中间有很多灰色区域，你最好的判断就是做出决定。
您可以尝试在DDD message board
上提出此问题答案 1 :(得分：0)
这两个选项似乎都描述了软件有助于编写软件的更重量级的鼠标驱动框架。 （这些是通常的嫌疑人 - 您直接或间接支付的框架。）
我认为有可能将模式和做法放在中间位置;你在哪里写软件，但大多数情况下你喜欢的东西。 （我认为关键词是与“模式”的强烈联系。）
一个很好的具体例子是新流行的MVC概念框架（及其类似）。这些可以非常一般地对待;并且您可能会或可能不会根据您的平台，背景和/或个人偏好选择支付工具。但我认为MVC等不会有很多不足或不堪重负的情况（但问题中提出的两个选项中的一个会更加合适。）
至少我真的很难找到一条中间路径，如果没有其他原因不这样做往往导致短生命周期模式和工具，以及可扩展性问题（问题直接引用。）< / p>