我无法清楚地理解领域驱动设计所提倡的自下而上方法的问题。有人可以简单地写一下或在写作方向上轻推我吗？我的意思是，在 Sql 世界中，我们有由表表示的实体，它们有关系、约束等。那么现在 DDD 提出的以类作为实体的新方法将如何使我们受益？但在此之前，正如问题所示，我需要了解自下而上方法带来的问题。
问问题
522 次
1 回答
6
在SapiensWorks 中，迈克解释得很好：
域不应该被基础设施细节污染。如果您从 db（自下而上的方法）开始，一切都会围绕它发展并受到它的约束。但是您不是为数据库构建应用程序，而是为域构建它，数据库只是一个持久性实现细节。
域是应用程序存在的原因，一切都应该围绕它。域不应该依赖于任何东西，尤其是不依赖于持久性实现细节。当您设计域实体时，他们应该对持久性一无所知。
我建议您在继续阅读此处之前阅读完整的帖子。
如果您首先设计持久性模式，则您没有考虑域；至少不是完全需要的深度。您正在设计效率、冗余、规范化、关系等而不是行为，稍后您将创建适合该持久性方案的实体。突然之间，你会发现在你的实体中做的事情毫无意义、奇怪和奇怪，只是为了匹配持久性模式、持久性实现和/或持久性技术，除非你对持久性重新设计进行迭代。
这两种方法，即为适应持久性和持久性重新设计迭代而设计的实体，都是不好的。第一个是因为糟糕的实体设计和SOLID中断；第二个因为是额外的工作和浪费时间。
DDD 提出的以类为实体的新方法将如何使我们受益？
良好的实体设计（这意味着良好的领域建模）和/或不会在持久性设计迭代中浪费时间。
于 2016-02-03T07:53:57.697 回答