自下而上的方法有什么问题

Question

我无法清楚地理解领域驱动设计所提倡的自下而上方法的问题。有人可以简单地写一下或在写作方向上轻推我吗？ 我的意思是，在 Sql 世界中，我们有由表表示的实体，它们有关系、约束等。那么，现在 DDD 提出的以类为实体的新方法将如何使我们受益？但在此之前，正如问题所示，我需要了解自下而上方法带来的问题。

Answer 1

在SapiensWorksMike 解释的很好：

域不应被基础设施细节污染。如果你 从 db 开始（自下而上的方法），一切都会围绕 它并且会受到它的约束。但是您不构建应用程序 对于数据库，您为域构建它，数据库只是一个 持久性实现细节。

域是应用程序存在的原因，一切都应该 被它吸引。域不应该依赖任何东西， 特别是没有关于持久性实现细节。当你 设计领域实体，他们应该不知道任何关于 持久性。

我建议您在继续阅读此处之前阅读完整的帖子。

如果您首先设计持久性模式，则您没有考虑域；至少不是完全需要的深度。您正在设计效率、冗余、规范化、关系等而不是行为，稍后您将创建适合该持久性方案的实体。突然间，你会发现在你的实体中做的事情毫无意义、奇怪和奇怪，只是为了匹配持久性模式、持久性实现和/或持久性技术，除非你对持久性重新设计进行迭代。

这两种方法，即为适应持久性和持久性重新设计迭代而设计的实体，都是不好的。第一个是因为糟糕的实体设计和SOLID 中断；第二个因为是额外的工作和浪费时间。

从类作为实体开始的新方法如何 DDD提出的对我们有利吗？

良好的实体设计（良好的领域建模意味着什么）和/或不会在持久性设计迭代中浪费时间。