【领域驱动设计】事务脚本、活动记录和领域模型

【本贴转载并翻译自 When to use domain driven development and database driven development】

    出于某种原因，Martin Fowler在其PoEAA一书中介绍了三种不同的模式：事务脚本（transaction script）、活动记录（active record）以及领域模型（Domain Model）。领域驱动设计使用的是领域模型模式，并引入了大量实现这种模型的模式与实践。

    Transaction script是一种没有任何分层结构的模式，在这种模式中，数据库的访问、数据的处理以及用户界面的处理都由同一段代码完成。

    与Transaction Script相比，Active Record往前迈进了一步，它将用户界面作为单独的一层，从其它内容中剥离出来，但你的业务逻辑和数据访问仍紧密地绑定在一起，使得你不得不根据数据库来建模你的活动记录。

    Domain Model则将你的领域模型从数据访问层中解耦出来，整个领域模型对数据访问一无所知。

    OK，现在我们来对问题进行进一步分析：

    这样的分层解耦自然会带来一些额外工作量，但同时也使得应用程序更具可维护性与可扩展性。

    当你的应用很少具有，甚至没有业务逻辑的时候，你可以选用Transaction Script模式。你只需要读写数据，而无需对其进行任何校验，或者整个校验过程是运行在数据库端的。

    Active Record则带来一些灵活性，因为你可以将UI从应用程序中解耦出来，从而可以使得相同的UI使用不同的应用机制，你也可以很方便地向业务对象中添加一些业务规则和数据校验机制。但由于模型仍然与数据库紧耦合，因此数据模型的更改会使你付出很大的代价。

    当你需要将业务逻辑从数据库解耦出来时，你可以选择使用Domain Model模式。这使你能够很方便地掌控应用程序的需求变更。领域驱动设计是一种方法，它能够使你更好地将这种灵活性应用在极为复杂的应用程序解决方案上，而无需关心数据库实现的具体细节。

    现在市面上有很多工具都可以使得数据库驱动的开发过程变得更加简单。例如，微软提供了可视化的网站设计解决方案，每张页面都与一份代码关联起来，这是一种非常典型的Transaction Script应用，开发简单的应用程序变得非常方便；Ruby on Rails具有支持Active Record的工具。由于这两种模式都有工具支持，我想，这大概是很多人愿意使用数据库驱动开发的主要原因。对于那些行为比数据更重要、更需要应对需求变更的复杂系统而言，领域驱动设计就是不错的选择。

【注：Sunny Chen所译，引用请注明出处。为使文章不至于那么生硬，译文在原文的基础上做了些小的变动，但在主要观点上未作任何夸辞渲染】