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

我无法清楚地理解自底向上方法的问题，而领域驱动设计正是针对这种方法提出的。有人能简短地写一下吗，或者让我朝着写的方向走？ 我的意思是，在Sql世界中，我们有由表表示的实体，它们有关系、约束等等。那么，DDD提出的以类作为实体的新方法对我们有什么好处呢？但在此之前，正如问题所表明的那样，我需要理解自下而上方法所带来的问题。

在Mike中，请详细解释：

域不应该被基础设施细节所污染。如果你 从db（botton up方法）开始，一切都会随之发展 它也将受到它的约束。但是您不构建应用程序 对于数据库，您为域构建它，数据库只是一个 持久性实现细节

域是应用程序存在的原因，所有内容都应该 被它吸引。域不应该依赖于任何东西， 尤其不是关于持久性实现的细节。当你 设计域实体时，他们应该什么都不知道 坚持

我建议你在继续阅读之前阅读完整的文章

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

设计用于适应持久性和持久性重新设计迭代的实体AProach都是不好的。第一种是因为实体设计不好而断裂；第二个原因是额外的工作和浪费时间

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

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