我对这个讨论还是比较陌生的，但即使冒着“无知”的风险，我也要问这个问题。为什么我们现在对'DDD'施加如此大的压力。我越是关注'DDD'，我的应用程序看起来就越复杂。而使用数据库为我的域建模有助于保持我的应用程序跨层保持一致。然后我可以使用SubSonic或L2S等DAL Helpers轻松访问该模型。这有什么不好的？即使在企业应用程序中？
为什么我们在经过考验的网站上努力创建一种新的域建模方式？
我愿意听到这里的纯粹主义者的意见。
答案 0 :(得分：5)
你不能卖掉旧的方法论，因为太多的项目都失败了，而且太多的人都知道旧的方法论。必须有一个新的上市。
如果您使用旧方法做得很好，那么使用有效的方法。注意新的东西，因为一些非常好的想法出现了。但这并不意味着旧的一切都是坏的和愚蠢的。通常，您可以在很大程度上将新想法融入旧模型中。
就像我不会用结构和函数指针做OOP。 ; - ）
答案 1 :(得分：4)
这实际上是一个非常好的问题，简短的回答是“你可以”。我们曾经这样做，并且有一整个企业（数据）建模领域。事实上，常见的OOD符号是从ERD演变而来的。
然而，我们发现，像这样的数据驱动设计有一些困难，其中最大的一个是数据库的自然结构不一定与代码的自然结构很好地匹配。
OOD在很大程度上源于希望更容易找到具有几个理想属性的代码结构：
设计思维的简易性最初来自Simula，它使用我们现在认为的“对象”进行模拟;在模拟中方便的是拥有与您正在模拟的事物相对应的软件实体。仅仅是后来，施乐的Alan kay等人认为这是一种更为通用的结构化方法。
关于变化下的稳健性的部分有许多父母，但其中最重要的部分之一是Dave Parnas，你写了几篇论文，确定了模块化的基本规则，我称之为Parnas定律：每个模块应该保留一个秘密，这个秘密是一个可能会改变的要求。
事实证明，通过将Parnas定律与Simula的“对象”概念相结合，可以与现实世界相对应，你倾向于来获得更多的系统设计在需求变化下比我们做事的旧方式更强大。 （并非总是如此，有时你需要狡猾，就像使用 Command 模式一样。大多数对象都是名词，有持久存在的东西。在Command模式中，理想的对象是动词< / em>，你做的事。）
然而，事实证明，该结构不一定是表示关系数据库中底层数据的好方法，因此我们最终得出“对象关系阻抗不匹配”问题：如何表示来自objectland的转换到数据库 - 土地。
答案 2 :(得分：3)
简短回答：如果您只需要一个允许用户编辑数据的CRUD系统，只需在后端数据库中构建一个Access前端（或使用您提到的脚手架框架）并将其称为一天。与域驱动系统相比，您应该能够减少70％的预算。
答案很长：采用数据驱动设计，业务模型的实现是什么样的？通常在为您的应用程序构建新功能几年之后，您会发现它遍布各处：表，视图，存储过程，各种应用程序服务，代码隐藏文件，演示者/ ViewModel等，并且到处都是重复的。当您与领域专家就他们要求的新功能进行对话时，您会不断尝试将业务语言翻译为实施语言，而且不会翻译。
通常最终会发生的事情是，您被迫在系统实施方面与业务进行通信，并且实现成为业务和开发人员在通信时被迫使用的“无所不在的语言”。这具有广泛的后果。业务领域的专家开始相信他们是实施领域的专家，他们开始要求实施方面的功能，而不是他们试图解决的业务需求。
此外，您会发现大多数数据驱动的实现都不遵循域的“概念轮廓”，并且系统的组件在如何将它们组合在一起以解决问题方面不是很灵活，因为他们没有与业务模型中的概念一对一地映射。当代码没有内聚时，更改和新功能可能需要在整个实现中进行修改。
Domain Driven-Design提供的工具使您的实施与商业模式非常相似，每个人都可以轻松地讲述业务语言。它允许您编写“可执行规范”来测试您的实现，但实际上您的域专家可以理解。