Viv*_*Dev 3 domain-driven-design bottom-up
我无法清楚地理解域驱动设计所倡导的自下而上方法的问题.有人可以写一下,或者在写方向上轻推我吗？我的意思是,在Sql世界中,我们有表格所代表的实体,它们有关系,约束等等.那么现在如何以DDD提出的类作为实体开始的新方法将如何使我们受益？但在此之前,正如问题所表明的那样,我需要了解自下而上方法所带来的问题.
在SapiensWorks中,迈克解释得非常好:
域名不应该受到基础设施细节的污染.如果你从db(botton up方法)开始,一切都会围绕它发展并受到它的约束.但是你没有为数据库构建应用程序,你为域构建它,数据库只是一个持久性实现细节.
域是应用程序存在的原因,一切都应该围绕它.域不应该依赖于任何东西,特别是不依赖于持久性实现细节.在设计域实体时,他们应该对持久性一无所知.
我建议你在继续阅读之前阅读完整的帖子.
如果您首先设计持久性模式,那么您不会考虑Domain; 至少,不是完全和需要的深层次.您正在设计效率,冗余,规范化,关系等非行为,之后您将创建适合该持久性方案的实体.突然间,除非重新设计持久性迭代,否则您将在实体中发现无意义,奇怪和奇怪的事情,只是为了匹配持久性模式,持久性实现和/或持久性技术.
两种aproaches,旨在适应持久性和持久性重新设计迭代的实体都很糟糕.第一个因为糟糕的实体设计和SOLID中断; 第二个是因为额外的工作和浪费时间.
如何通过DDD提出的以类为实体的新方法对我们有利吗？
良好的实体设计(这意味着良好的域建模)和/或不是持久性设计迭代中的时间.