什么时候使用域驱动开发和数据库驱动开发？

Question

什么时候应该使用数据库驱动开发，什么时候应该使用域驱动开发，谁能给出一个好的答案。这两种开发方法在各自受人尊敬的领域都有其重要性。但我不太清楚在哪种情况下哪种方法是合适的。有什么建议吗？

Answer 1

首先是一些背景知识，Martin Fowler在他的书“企业架构的模式”中实际上描述了三种不同的“模式”。事务脚本、活动记录和域模型。DDD使用领域模型模式作为整体架构，并描述了许多实践和模式来实现和设计此模型。

事务脚本是一种没有任何分层的架构。同一段代码读/写数据库，处理数据并处理用户界面。

Active Record则更上一层楼。您拆分了您的UI，您的业务逻辑和数据层仍然存在于模仿数据库的活动记录对象中。

域模型将驻留在模型中的业务逻辑与数据层解耦。模型对数据库一无所知。

现在我们来看有趣的部分：

这种额外分离的成本当然是额外的工作。好处是更好的可维护性和灵活性。

如果业务规则很少或没有业务规则，只想进行数据输入而没有验证步骤，或者所有的验证都在数据库中实现，那么事务脚本是很好的选择。

Active record为此增加了一些灵活性。因为你可以解耦你的UI，例如，你可以在应用程序之间重用它下面的层，你可以很容易地向业务对象添加一些业务规则和验证逻辑。但是，因为它们仍然与数据库紧密耦合，所以数据模型中的更改可能会非常昂贵。

当您想要将业务逻辑与数据库解耦时，可以使用域模型。这使您能够更轻松地处理更改的需求。域驱动设计是一种最佳地使用这种增加的灵活性来实现复杂解决方案的方法，而无需绑定到数据库实现。

大量的工具使得数据驱动的解决方案变得更容易。在微软的空间中，很容易在视觉上设计网站，所有的代码都在网页后面。这是一个典型的事务脚本解决方案，非常适合创建简单的应用程序。Ruby on rails提供了一些工具，可以让处理活动记录对象变得更容易。当您需要开发更简单的解决方案时，这可能是采用数据驱动的原因。对于行为比数据更重要，并且很难预先定义所有行为的应用程序，DDD是可行的方法。

Answer 2

我问过一个类似的问题：Where do I start designing when using O/R mapping? Objects or database tables?

从我得到的答案中，我会说:除非你有具体的理由使用数据库驱动的开发，否则就使用域驱动的开发。

Answer 3

这样想吧。

问题域永远存在。您的类定义将反映该域的永恒特性。

关系数据库是当今首选的持久性机制。在某种程度上，我们将超越这一点，转向一些“更新的”，“更好的”，“不同的”。数据库设计只是一种实现；它更多地反映了解决方案体系结构，而不是问题域。

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