何时使用域驱动开发和数据库驱动开发？ [英] When to use domain driven development and database driven development?

问题描述

何时应该使用数据库驱动的开发以及何时应该使用域驱动的开发，任何人都可以给出很好的答案。这两种发展方法在各自受尊重的领域都具有重要意义。但是我不清楚哪种方法适合哪种情况。有什么建议吗？

Can anybody have good answer when should be database driven development be used and when should domain driven development be used. These both development approach have their importance in their respected areas. But I am not so clear which approach is appropriate in what type of situation. Any recommendation?

推荐答案

首先出于某种背景，Martin Fowler在他的《企业架构模式》中实际上描述了三种不同的模式。事务脚本，活动记录和域模型。 DDD将域模型模式用于整个体系结构，并描述了许多实践和模式来实现和设计该模型。

First for some background, Martin Fowler actually described three different "patterns" in his book Patterns of Enterprise Arcitecture. Transaction Script, Active Record and Domain Model. DDD uses the domain model pattern for the overall architecture and describes a lot of practices and patterns to implement and design this model.

事务脚本是一种您不需要的体系结构有任何层次感。同一段代码读取/写入数据库，处理数据并处理用户界面。

Transaction script is an architecture where you don't have any layering. The same piece of code reads/writes the database, processes the data and handles the user interface.

Active Record是从此迈出的一步。拆分UI后，您的业务逻辑和数据层仍然生活在根据数据库建模的活动记录对象中。

Active Record is one step up from that. You split off your UI, your business logic and data layer still live together in active record objects that are modeled after the database.

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

A domain model decouples the business logic that lives in your model from your data-layer. The model knows nothing about the database.

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

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

当您没有或很少有业务规则，您只想进行数据输入并且没有验证步骤或所有验证都在数据库中实现时，事务脚本非常有用。 。

活动记录为此增加了一些灵活性。因为您将UI分离，所以您可以（例如）在应用程序之间重用其下面的层，因此可以轻松地向业务对象添加一些业务规则和验证逻辑。但是由于这些仍然与数据库紧密耦合，因此数据模型中的更改可能非常昂贵。

当您要将业务逻辑与数据库分离时，可以使用域模型。这使您能够轻松应对不断变化的需求。域驱动设计是一种最佳利用此附加灵活性来实现复杂解决方案的方法，而不必依赖于数据库实现。

And now we come to the interesting part:
The cost of this added separation is of course extra work. The benefits are better maintainability and flexibility.
Transaction script is good when you have few or no business rules, you just want to do data-entry and have no verification steps or all the verification is implemented in the database.
Active record adds some flexibility to that. Because you decouple your UI you can for example reuse the layer beneath it between applications, you can easilly add some business rules and verification logic to the business objects. But because these are still tightly coupled to the database changes in the datamodel can be very expensive.
You use a domain model when you want to decouple your business logic from the database. This enables you to handle changing requirements easier. Domain Driven Design is a method to optimally use this added flexibility to implement complex solutions without being tied to a database implementation.

许多工具使数据驱动型解决方案更加容易。在Microsoft领域，直观地设计所有代码都位于网页后面的网站非常容易。这是一个典型的事务脚本解决方案，对于轻松创建简单的应用程序来说非常有用。 Ruby on Rails的工具使使用活动记录对象的工作更加轻松。当您需要开发更简单的解决方案时，这可能就是采用数据驱动的原因。对于行为比数据更重要并且很难预先定义所有行为的应用程序，DDD是必经之路。

Lots of tooling makes data-driven solutions easier. In the microsoft space it is very easy to visually design websites where all the code lives right behind the web-page. This is a typical transaction script solution and this is great to easilly create simple applications. Ruby on rails has tools that make working with active record objects easier. This might be a reason to go data-driven when you need to develop simpler solutions. For applications where behaviour is more important than data and it's hard to define all the behaviour up front DDD is the way to go.

这篇关于何时使用域驱动开发和数据库驱动开发？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！