我无法清楚地理解领域驱动设计所倡导的自下而上方法的问题。有人可以简短地写或推动我写的方向吗？我的意思是，在SQL世界中，我们有由表表示的实体，它们有关系，约束等等。那么，现在DDD提出的从类作为实体开始的新方法将如何使我们受益？但在此之前，正如问题所表明的那样，我需要了解自下而上的方法所带来的问题。
在SapiensWorks中，Mike解释得很好：
域不应受到基础结构详细信息的影响。如果你 从DB(Botton Up方法(开始，一切都会围绕它发展 它并将受到它的约束。但是您不构建应用程序 对于数据库，您为域构建它，数据库只是一个 持久性实现详细信息。
域是应用程序存在的原因，一切都应该 在它周围有吸引力。域不应依赖于任何内容， 尤其是不是持久性实现细节。当你 设计域实体，他们应该一无所知 坚持。
我建议您在继续阅读此处之前阅读完整的帖子。
如果你首先设计持久性模式，你没有考虑域;至少没有完全考虑深度。您正在设计效率、冗余、规范化、关系等，而不是行为，稍后您将创建适合该持久性方案的实体。突然间，你会发现在你的实体中做了一些毫无意义、奇怪和奇怪的事情，只是为了匹配持久性架构、持久性实现和/或持久性技术，除非你进行持久性重新设计的迭代。
这两个 aproache，旨在适应持久性和持久性重新设计迭代的实体，都是不好的。第一个是因为糟糕的实体设计和 SOLID 断裂;第二个是因为额外的工作和浪费时间。
良好的从类作为实体开始的新方法如何 DDD提出的建议会让我们受益吗？
实体设计(这意味着良好的域建模(和/或不浪费持久性设计迭代的时间。