我对这个讨论相当陌生，但即使冒着听起来“无知”的风险，我也必须提出这个问题。为什么我们现在对'DDD'如此强调。我对“DDD”的研究越多，我的应用程序似乎就越复杂。而使用数据库对我的域进行建模有助于使我的应用程序跨层保持一致。然后我可以使用 DAL Helpers（如 SubSonic 或 L2S）轻松访问该模型。这有什么不好？即使在企业应用程序中？
当我们有一个经过尝试和测试的方法时，为什么我们要努力创建一种新的域建模方法？
我愿意听取这里纯粹主义者的意见。
Ali Kazmi
问问题
1164 次
3 回答
5
你不能出售旧的方法论，因为太多的项目失败了，而且有太多人知道旧的方法论。必须有一个新的上市。
如果您对旧方法做得很好，那么请使用有效的方法。一定要注意新事物，因为会出现一些非常好的想法。但这并不意味着旧的一切都是坏的和愚蠢的。通常你可以在很大程度上将新想法融入到旧模型中。
确实是时候采取行动了。就像我不会用结构和函数指针做 OOP。;-)
于 2009-04-01T05:28:00.607 回答
4
这实际上是一个非常好的问题，简短的回答是“你可以”。我们过去是这样做的，并且有整个企业（数据）建模领域。事实上，常见的 OOD 符号是从 ERD 演变而来的。
然而，我们发现，像这样的数据驱动设计有一些困难，其中最大的困难是数据库的自然结构不一定与代码的自然结构很好地匹配。
在很大程度上，OOD 源于希望更容易找到具有几个理想属性的代码结构：
- 应该很容易想到设计
- 它在变化下应该是健壮的。
易于思考的设计最初来自 Simula，它专门使用了我们现在认为的“对象”进行模拟；在模拟中拥有与您正在模拟的事物相对应的软件实体很方便。直到后来，施乐的 Alan kay 等人才将其视为一种更通用的结构化方法。
关于变化下的鲁棒性的部分有很多父母，但其中最重要的一位是 Dave Parnas，你写了几篇论文，确定了模块化的基本规则，我称之为帕纳斯定律：每个模块都应该保密，并且这个秘密是一个可能会改变的要求。
事实证明，通过将 Parnas 定律与 Simula 的“对象”概念相结合，将“对象”对应于可以在现实世界中识别的事物，您往往会获得在需求变化下比我们所做的旧方法更健壮的系统设计事物。（并非总是如此，有时你必须狡猾，就像命令模式一样。大多数对象是名词，具有持久存在的东西。在命令模式中，理想的对象是动词，你做的事情。）
然而，事实证明，这种结构不一定是表示关系数据库中底层数据的好方法，所以我们最终会遇到“对象关系阻抗不匹配”问题：如何表示从对象域到数据库的转换——土地。
于 2009-04-01T05:28:07.390 回答
3
简短的回答：如果您只需要一个允许用户编辑数据的 CRUD 系统，只需为您的后端数据库构建一个 Access 前端（或使用您提到的脚手架框架）并收工。与域驱动系统相比，您应该能够削减 70% 的预算。
长答案：使用数据驱动的设计，业务模型的实现是什么样的？通常在为您的应用程序构建新功能几年后，您会发现它无处不在：表、视图、存储过程、各种应用程序服务、代码隐藏文件、演示者/视图模型等，到处都是重复的. 当您与领域专家就他们要求的新功能进行对话时，您一直在尝试将业务语言翻译成围绕您的实施的语言，但它只是无法翻译。
通常最终发生的情况是，您被迫在系统的实现方面与业务进行通信，而实现成为业务和开发人员在通信时被迫使用的“无处不在的语言”。这会产生广泛的后果。业务领域的专家开始相信他们是实现领域的专家，他们开始从实现的角度来要求特性，而不是他们试图解决的业务需求。
此外，您会发现大多数数据驱动的实现不遵循领域的“概念轮廓”，并且系统的组件在如何将它们组合在一起来解决问题方面不是很灵活，因为它们不不要与业务模型中的概念一一对应。当代码没有凝聚力时，更改和新功能可能需要在整个实现中进行修改。
领域驱动设计提供了使您的实施与业务模型非常相似的工具，以至于每个人都可以轻松地使用业务语言。它允许您编写“可执行规范”来测试您的实现，但您的领域专家实际上可以理解。
于 2009-09-24T03:40:50.870 回答