《企业应用架构模式》学习笔记（一）

写在前面

         程序员的迷茫分两种，一种是纯技术迷茫，一种是设计上的迷茫。只是个人这样区分，关于第一种就只能看各种纯技术的书籍，以解决技术问题为目的，比如《Effective Java》，d第二种就是碰到一个独立项目的时候如何来对项目进行架构，毕竟不管项目大小，都需要架构，而在这些不论大小的项目的架构中是能学会很多知识的，所以如果这时找不到方向，也就迷茫了。其实纯技术的迷茫还好解决，毕竟随着经手的项目越来越多，遇到的问题也会越来越多，然后问问“谷老师”、“度娘”之类的基本都能逐渐不迷茫，但第二种不一定，最好是能够借助于一些前辈的总结来收获自己的知识，这种方式会比较好，成长也会更快。废话多了，这个系列将会记录自己在学习《企业应用架构模式》一书中的体会，也作为自己的鞭策。

本次包括第一章和第二章内容。

1、  关于分层

关于分层的概念和优点就不多说了，分层的难点在于不明确要分哪些层，以及这些层各自的职责是什么？很多开发者即便在应用中使用了分层的设计，但几个层次之间还是有逻辑的交叉，这种分层反而加重的开发和维护的负担，所以一旦采用了分层的设计方法，就要明确每一层的职责。一个简单的方式就是替换思考，假设将某一层使用另外的方式替换掉，系统能不能和之前一样正常运行，比如系统持久层的实现，为了满足不同数据库之间的无缝切换，就需要对不同的数据库分别实现，但是持久层对于上层的领域层是封闭的，这也说明层与层之间的隔离性：上层对下层的具体实现不做过多了解，只需要知道如何调用下层公开的接口即可。

         分层应用有一个准则：下层尽量不要对上层产生依赖。一旦出现这种情况，系统架构将会显得很脆弱，比如修改上层代码有可能导致下层的变化，这种变化不应该是逆向的。

当讨论分层的时候，常常不易区分layer和tier的区别，在人们的理解中，tier通常意味着物理上的分离，比如客户/服务器通常被称为”two-tier system”，而作者讨论的是逻辑上的分层—layer。

2、  三个基本层次及各自的职责

三个基本层次包括：

         表现层：提供服务、显示信息等职责。处理用户和系统的交互。主要的职责就是向用户显示信息并将从用户那里获取的信息解释成为领域层或数据源层上的各种动作。

         数据源层：与数据库、消息系统或其他软件应用进行通信。主要关注与其他系统的交互，而这些系统则代表应用完成相应的任务。但现实中大部分都是进行数据持久化。

领域层：业务逻辑所在地，也是系统的真正核心。主要职责是根据用户输入的数据或已有的数据进行逻辑运算，对从表现层输入的数据进行验证，以及根据从表现层传来的命令来确定要调用哪些数据源逻辑。

一般来讲，领域层应该对表现层隐藏数据源层的所有服务，但在很多简单的系统中也存在表现层直接访问数据源层，然后返回数据到表现层，而领域层则只是对数据返回到表现层之前进行必要的处理，这种结构运行的也很良好，但不推荐这种方式。

作者对本书的层次讨论范围做了限定，仅仅只在经典的三个基本层次上进行讨论，而其他的分层基本上都是对经典三层的扩充或修改，比如在领域层添加一层很薄的服务层，一般我们称之为外观层。

         如何区分哪些是“领域逻辑”，哪些是“非领域逻辑”呢？确定一个逻辑（方法）是否放到领域层或表现层有一种简单的方法，那就是，再增加一个表现层，如果这个方法需要重复编写，那么这个逻辑就应该是领域层的逻辑。比如，如果判断经理和职员来显示某个功能的逻辑，对系统来说就应该传入用户的id，传出true或者false，界面显示只依赖于true和false。

3、  三种组织领域逻辑的方式

领域逻辑的组织分为三种：事务脚本、领域模型、表模块。

事务脚本：大多数企业的应用都可以被看作是一系列的事务，一个事务可能将某种信息看作是以特定方式组织的，然后另一事务会改变他。事务逻辑脚本将所有的事务逻辑组织成单个过程，在过程中直接调用数据库，或者用一个简单的数据封装器。每个事务都由自己的事务脚本，尽管事务间的公共子任务可以被重构为方法。许多事务脚本的设计中都有直接操作数据库的操作，有些把SQL语句直接放到数据库中。看了这段话，我才算认清楚我以前的代码好多都是这种低效的事务脚本。

         事务脚本也有如下优点：

                   大多数开发者都能理解的过程模型；

                   事务控制方便，脚本开始就是事务的开始，脚本结束就是事务的结束。

领域模型：当业务逻辑比较复杂的时候，就需要引入领域模型来解决问题了，在领域模型中，不再是由一个过程来控制用户某个动作的逻辑，而是由领域模型中的各个对象来承担相应职责部分的逻辑。而这就是OOD的方法。

         表模块：表模块是用一个类对应数据库中一个表来组织领域逻辑，而且使用单一的类来包含对数据进行的各种操作。它与领域逻辑的主要区别在于，如果有许多订单，领域模型使用多个类来处理订单而表模块使用单一的类来处理所有订单。此处的表模块并不是必须针对每一个数据库物理表创建一个表模块，其更多的是针对一个虚拟表结构（如物理视图或者一个查询语句）创建模块。

表模块的入口：表模块封装的是一个记录集，那么形成记录集的入口通常有两个，一个是在构造函数或者初始化入口中使用查询语句，另一种就是在入口中传递一个表数据(如recordset)，这样的优点是封装了数据的生成，这个表模块可以面对多个数据源，并且你可以不用数据库就测试领域逻辑。缺点是多增加了一个用来生成数据的类。

4、  是否设立服务层

在使用领域模型和表模块的组织结构是最好是能在其上添加一层很薄的服务层，该服务层中没有业务逻辑，表现层逻辑和领域层交互完全通过该服务层进行，就像应用程序的API一样。

为了将事务控制和安全检查等非业务逻辑同领域层进行解耦，服务层也是最好的地方，在实际开发中，我们可以使用AOP的方式对这些事务控制和安全检查进行抽象，然后植入到相应的服务层API上达到解耦的目的。

业务逻辑的分类：服务层是一种组织业务逻辑的模式，通常将业务逻辑分为两类，应用逻辑和领域逻辑，领域逻辑解决领域问题，应用逻辑与应用的职责相关，通常解决工作流、应用集成的问题。如果应用逻辑与领域逻辑分离，则能使领域逻辑更好的复用。

有两种方式来应用服务层，其一是OOD中推荐的薄层服务层，也就是我们说的服务层贫血（相应的是充血型领域模型），这种服务层只负责将表现层的数据传输到相应的领域对象中；其二是将所有的业务逻辑全部放到服务层中，而下层的领域对象中只是简单的数据载体，这种被成为服务层充血模型，这是两种极端的应用场景。

作者建议：如果确实要设置服务层，建议使用最小化服务层。

         以上是看了书的前两章，写点笔记，也好做个记录。涉及到的理论比较多，但有开发经验的基本上都能看懂，我觉得是这样，呵呵。在看书的基础上也看了看别人的笔记，有些总结的蛮经典的，至少我觉得比我总结得好得多。欢迎批评指正。以下有两个链接可以参考：

后知后觉--企业应用架构模式：http://www.uml.org.cn/zjjs/201001064.asp

数据源架构模式之行数据入口：http://www.phppan.com/2010/09/enterprise-application-architecture-2-rowdatagateway/

表模块模式：http://www.blogjava.net/wfeng007/archive/2007/12/07/35021.html