自下而上方法有什么问题

Question

我无法清楚地了解自下而上方法的问题 Domain Driven Design 提倡的问题。有人可以写一下，或者在写方向上轻推我吗？ 我的意思是，在Sql世界中，我们有表格所代表的实体，它们有关系，约束等等。那么现在如何以DDD提出的类作为实体开始的新方法将如何使我们受益？但在此之前，正如问题所表明的那样，我需要了解自下而上方法所带来的问题。

Answer 1

在SapiensWorks迈克解释得非常好：

  

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

     

域名是应用程序存在的原因，应该是一切   在它周围吸引力。域名不应该依赖于任何东西，   特别是在持久性实现细节上。当你   设计域实体，他们应该不知道任何事情   持久性。

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

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

两种aproaches，旨在适应持久性和持久性重新设计迭代的实体都很糟糕。第一个是因为糟糕的实体设计和SOLID中断;第二个是因为额外的工作和浪费时间。

  

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

良好的实体设计（这意味着良好的域建模）和/或不是持久性设计迭代中的时间。