何时使用域驱动开发和数据库驱动开发？

当应该使用数据库驱动的开发以及何时应该使用域驱动开发时,任何人都可以得到很好的答案.这两种发展方法都在其受尊重的领域中具有重要意义.但我不清楚哪种方法适合哪种情况.有什么建议？

首先,Martin Fowler在他的"企业架构模式"一书中描述了三种不同的"模式".事务脚本,活动记录和域模型.DDD将域模型模式用于整体架构,并描述了许多实现和设计此模型的实践和模式.

事务脚本是一种您没有任何分层的体系结构.同一段代码读/写数据库,处理数据并处理用户界面.

Active Record是一步之遥.您拆分UI,业务逻辑和数据层仍然存在于数据库之后的活动记录对象中.

域模型将模型中存在的业务逻辑与数据层分离.该模型对数据库一无所知.

现在我们来到有趣的部分:
增加分离的成本当然是额外的工作.优点是更好的可维护性和灵活性.
当您拥有很少或没有业务规则时,事务脚本很好,您只想进行数据输入并且没有验证步骤或者所有验证都在数据库中实现.
活动记录为此增加了一些灵活性.因为您可以解耦UI,例如在应用程序之间重用它下面的层,您可以轻松地向业务对象添加一些业务规则和验证逻辑.但是因为这些仍然与数据库紧密耦合,数据模型中的变化可能非常昂贵.
当您想要将业务逻辑与数据库分离时,可以使用域模型.这使您可以更轻松地处理变更的需求.域驱动设计是一种最佳地利用这种增加的灵活性来实现复杂解决方案而不依赖于数据库实现的方法.

大量工具使数据驱动的解决方案更容易.在微软空间中,很容易在视觉上设计所有代码都位于网页后面的网站.这是一个典型的事务脚本解决方案,这对于轻松创建简单的应用程序非常有用.Ruby on rails提供了一些工具,可以更轻松地处理活动记录对象.当您需要开发更简单的解决方案时,这可能是数据驱动的原因.对于行为比数据更重要的应用程序而言,很难在前面定义所有行为DDD是要走的路.

我问了一个类似的问题:在使用O/R映射时我从哪里开始设计？对象或数据库表？

从我得到的答案我会说:除非你有充分的理由使用数据库驱动开发,否则使用域驱动开发.

这样想吧.

问题域永远存在.您的类定义将反映域的永恒特征.

关系数据库是当今首选的持久性机制.在某些时候,我们将超越这个"更新","更好","不同"的东西.数据库设计只是一个实现; 它反映了解决方案架构而不是问题域.

因此,它首先是域名.类反映了问题领域和普遍真理.关系数据库和ORM分别排在第二和第三位.最后,填写模型周围的其他内容.