什么时候应该使用数据库驱动开发以及什么时候应该使用域驱动开发，任何人都可以有好的答案吗？这两种发展方法在各自的领域都有其重要性。但我不太清楚哪种方法适合哪种情况。有什么推荐吗？
infynyxx
问问题
13233 次
6 回答
47
首先是一些背景知识，Martin Fowler 在他的《企业架构模式》一书中实际上描述了三种不同的“模式”。事务脚本、活动记录和域模型。DDD 将域模型模式用于整体架构，并描述了许多实践和模式来实现和设计该模型。
事务脚本是一种没有任何分层的架构。同一段代码读取/写入数据库、处理数据并处理用户界面。
Active Record 比这更上一层楼。你分离了你的 UI，你的业务逻辑和数据层仍然一起存在于以数据库为模型的活动记录对象中。
域模型将模型中的业务逻辑与数据层分离。该模型对数据库一无所知。
现在我们来到了有趣的部分：
这种增加分离的成本当然是额外的工作。好处是更好的可维护性和灵活性。
当您的业务规则很少或没有时，事务脚本很好，您只想进行数据输入并且没有验证步骤或所有验证都在数据库中实现。
活动记录为此增加了一些灵活性。因为您解耦了您的 UI，您可以例如在应用程序之间重用它下面的层，您可以轻松地将一些业务规则和验证逻辑添加到业务对象。但是由于这些仍然与数据库紧密耦合，因此数据模型中的更改可能非常昂贵。
当您想将业务逻辑与数据库分离时，您可以使用域模型。这使您能够更轻松地处理不断变化的需求。领域驱动设计是一种优化使用这种增加的灵活性来实现复杂解决方案的方法，而无需绑定到数据库实现。
许多工具使数据驱动的解决方案更容易。在 microsoft 空间中，视觉设计网站非常容易，其中所有代码都位于网页后面。这是一个典型的事务脚本解决方案，非常适合轻松创建简单的应用程序。Ruby on rails 具有使使用活动记录对象更容易的工具。当您需要开发更简单的解决方案时，这可能是采用数据驱动的原因。对于行为比数据更重要并且很难预先定义所有行为的应用程序，DDD 是要走的路。
于 2008-11-21T12:49:08.600 回答
7
我问过一个类似的问题：使用 O/R 映射时我从哪里开始设计？对象还是数据库表？
从我得到的答案中，我会说：除非您有具体的理由使用数据库驱动开发，否则请使用域驱动开发。
于 2008-11-21T12:50:34.120 回答
7
这样想吧。
问题域永远存在。您的类定义将反映该领域的永恒特征。
关系数据库是当今首选的持久性机制。在某个时候，我们会超越这个，转向“更新”、“更好”、“不同”的东西。数据库设计只是一种实现；它更多地反映了解决方案架构而不是问题域。
因此，它首先是域。类反映了问题域和普遍真理。关系数据库和 ORM 位居第二和第三。最后，在模型周围填写其他内容。
于 2008-11-21T12:59:50.090 回答
2
作为 mendelt 帖子的旁注，我觉得有第四种模式：一种分层模式，将业务逻辑与持久性和存储分开，但不使用“实体”或“业务对象”。如果您愿意的话，是事务/操作脚本和 DDD 之间的中间点。
在我工作过的许多系统中，持久层（存储库）直接使用 SqlClient 并将数据集返回给调用服务。服务执行决策并编译通过控制器发送给用户的视图。您可能会将服务层视为业务模型，您是对的，但它不是 DDD 意义上的“域”模型。尽管如此，所有业务逻辑都发生在这一层期间。每一层都有它的工作。视图显示数据，控制器确定视图，持久层处理存储，服务在控制器和持久性之间工作。
重点是：DDD 是一种通过 Ul、测试和代码来定义业务的方法。它与实体、值对象和聚合无关。这些东西只是 OOP 纯粹主义者对 DDD 方法的副产品。
只是更多的想法供您考虑。
于 2011-11-15T04:56:30.373 回答
1
对于复杂的业务模型，我更喜欢 ActiveRecord 和 DDD 的混合。域对象知道如何保存自己，并且数据操作是针对存储库完成的（如果您将存储库视为将数据作为集合公开给模型的东西，nHibernate 可以充当通用存储库）。业务逻辑驻留在领域实体中，甚至可以完成一些值类型的封装，尽管只有在有业务需要时才可以。DDD 的一些实现倾向于删除所有公共设置器，并且只通过方法修改实体。除非有非常好的业务需求，否则我不喜欢这种实现。
在我看来，这个实现让您可以轻松使用 ActiveRecord 和 DDD 的业务逻辑封装。
于 2012-08-20T15:49:48.700 回答
0
领域驱动开发肯定是要走的路。它更有意义并增加了灵活性。
于 2010-09-27T23:46:49.590 回答