《企业应用架构模式》之事务脚本、表模块、领域模型

大师之所以称之为大师，就是因为站的高度跟普通人不一样。

Martin Fowler在《企业应用架构模式》中将企业应用的模式分为三种：事务脚本、表模块、领域模型，这三种模式是对应用程序开发方式的高度抽象。

因为大师的思维高度，加之翻译成中文之后的蹩脚名词，很久才对这三种模式有了一些认识，本文讲讲个人的理解，不对之处请您指正。

一、事务脚本

首先这种模式，从字面上来看上事务驱动的，而且上通过脚本来实现的。对于刚刚开始程序开发的新手来说，这种模式上最被常用的，因为它最简单，最容易理解。

例如：做一个查询的小程序，那么首先会考虑用户输入查询值，点击查询按钮，然后程序通过SQL语句到数据库查询，查询返回结果到界面显示。这样一个用例通过线性的脚本来思考，实现时也通过这流程进行。

二、表模块

这种模式比较看重数据库，先考虑好有哪些数据要管理，然后设计好数据库表，剩下的就是增删改查的代码和界面了。

例如：做一个选课系统，首先考虑要有课堂、课程、教师、学生、教师与课堂关系、学生选课信息等等这些数据，然后设计出数据库表，再实现对这些数据库表增删改查的界面和数据库访问代码。

三、领域模型

这种模式上最符合面向对象的，从领域层（业务层）入手考虑，将领域模型抽象，建立Class，然后再考虑数据库如何保存，UI如何设计。

例如：上述选课系统，不是先考虑数据库，而是各领域对象会有哪些，通过类的关系来表示业务对象之间的关系，例如课堂类会有教师属性、所选课学生列表对象等。

事务脚本模式上最容易理解的，软件开发入门者就是这样的思路，实现最容易，但是最经不起需求的变化。

表模块模式上.NET帮派最喜欢的模式，微软推崇的DataSet、DataTable从UI一直贯穿到DB，感觉在UI上操作数据库表一样，超级简单，甚至有些控件直接绑定，代码不需要自己写多少，VS IDE和控件帮开发者搞定了，但是其实这样会把程序员“惯坏了”，虽然开发容易，但是对原理不够理解，对面向对象的思想更无法深入了解。虽然本人也上.NET帮派，但是一直认为需要向Java阵营学习的东西太多了。个人以为要理解面向对象，尽量远离DataTable。

对于企业应用中最有价值的就是业务领域层，技术实现上最多就是数据库的增删改查和UI，它的特点明显与其他类型的软件开发，如系统应用、多媒体、游戏等不同。业务的地位尤其重要，表现在业务复杂性、多变性两个方面，而面向对象的开发思想正式应对这类问题的，抽象、复用、适应变化等特点在处理起这种复杂业务的应用系统时相比其他模式更加便利。

对于三种模式，个人认为适用于不同规模的应用开发，简单的小程序可以考虑事务脚本模式将会节省设计的工作量，对于业务规模不大、领域逻辑变化不大的应用可使用表模块、而对于业务复杂、需求多面的应用建议使用更加面向对象的领域模型进行设计。