前八章主要从宏观的高度，大的方面来表述一个企业应用应该有 哪些方面的内容，如何开发企业应用的简单介绍。后面十个章节是本书的主体，是关于模式的详细参考手册，每个模式都给出使用方法和实现信息，且有相关代码示例。
事务脚本
使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。事务脚本将所有这些逻辑组织成单个过程，在过程中直接调用数据库，或者通过一个简单的数据库封装器。
运行机制
使用事务脚本时，领域逻辑主要通过系统所执行的事务来组织，如预定一个酒店房间，过程中有查找空房间、计算价格、更新数据逻辑。
可以用两张方法来把事务脚本组织成类，最常用的方法是将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起。另一种方法则是每一个事务脚本对应一个类，此时需使用命令模式。
使用时机
事务脚本胜在简单，对于只有少量逻辑的应用程序来说，是好的选择。
收入确定例子
假设某公司出售三种产品：文字处理软件、数据库、电子表格。其中，文字处理软件当天入账，电子表格当天入1/3,60天后再如1/3，剩下的90天后再入账，数据库当天入账1/3，30天后入账1/3，60天后入账1/3。
本示例使用了两个事物脚本：一个用来计算合同的收入确认，一个用来查询合同在指定日之前已经确认的收入额，数据库有三张表，分别记录产品、合同和收入确认。
Create table products(id,name,type)
Create table contracts(id,product,revenue,dateSigned)
Create table revenueRecogmitions(contract,amount,recognizedon)
第一个脚本用来计算在指定日期前的确认额，分为两步：首先在收入确认表中选择相应的行；然后相加计算总数。
然后再从入口返回的结果集上使用脚本来计算总额。
服务脚本实现了业务逻辑
在java系统中，收入确认服务可能是一个类或者是一个会话bean。上面的例子比较简单，但是当规则变得更为复杂时，就搞不定了。
领域模型
运行机制
在应用程序中使用领域模型需要建立一个完整的由对象组成的层，来对目标业务领域建模。数据和处理一般整合在一起，从而使得数据和数据之上的操作紧密聚合。
面向对象的领域模型通常看起来与数据库模型类型，但有很多不同之处，领域模型混合数据和处理过程，拥有多值属性和复杂的关联网，并且使用继承。
由此，领域模型衍生出两种风格：
- 简单领域模型看起来和数据库设计类似，每一个表对应一个领域对象。
-
复杂领域模型与数据库设计不同，使用继承、策略和其他设计模式。但它到数据库的映射比较困难，简单领域模型可以使用活动记录，而复杂领域模型则使用数据映射器。
由于业务行为经常变化，因此易于修改、建造和测试对领域层来说是否重要，所有有很多分层模式，让各层之间依赖尽可能少。
Java实现
领域模型应当使用细粒度的对象，有细粒度的接口，当实体beans是远程的时候，性能十分底下，这个时候领域模型中只使用实体beans的本地接口。
另外方法是使用正常java对象，POJO（普通java对象，plain old java objects），POJO领域模型易于封装、创建快捷、可在EJB容器之外测试和运行。
表模块
面向对象的关键思想之一是将数据与对该数据操作的行为绑定在一起。如果有一个类，我们就可以执行类的操作，访问关联和收集数据。
在表模块中以一个类对应数据库中的一个表来这组织领域逻辑，与领域模型的区别是：领域模型每一个订单都有一个对象，而表模块则只用一个对象来处理所有的订单。
服务层
通过一个服务层来定义应用程序边界，在服务层中建立一组可用的操作集合，并在每个操作内部协调应用程序的相应。
企业级应用通常需要提供不同种类的接口来访问内部存储的数据和所实现的逻辑：例如数据加载器，用户界面，以及系统集成入口。
服务层定义了应用的边界和从接口客户层角度所能看到的可用操作集，它封装了应用的业务逻辑、事务控制以及其操作实现中的响应协调。
运行机制
-
业务逻辑的种类
像事务脚本和领域模型一样，服务层是一种组织业务逻辑的模式。一般将业务逻辑分成两类：领域逻辑和应用逻辑
- 领域逻辑只与问题领域有关，如计算合同收入确认的策略
- 应用逻辑与应用的职责有关，如关于收入确认计算的相关事宜，通知合同管理者、系统集成等。
在避免领域逻辑的重复及利用经典模式来管理复杂性方面，领域模型优于事务脚本，但是，将应用逻辑置于纯粹的领域对象类中也会带来一些不良后果。
- 如果领域对象中实现了针对具体应用的逻辑，或者依赖于针对具体应用的软件包，则会降低该类在应用之间的可重用性（）
- 如果将来需要在如工作流工具之类的软件中重现应用程序逻辑，则将两种逻辑混杂在同一个类中会使得这一工作比较困难。
基于这些理由，服务层把每种业务逻辑分解成为一个单独的层，从而在获得分层的常规收益时，使得纯粹的领域对象类可以在不同应用之间更好地被重用。
- 实现方法
- 领域外观方法，服务层以领域模型之上的瘦外观集合方式实现，负责实现外观的类不包含任务业务逻辑，所有业务逻辑均由领域模型实现，bean实现大部分逻辑，服务层少量接口
- 操作脚本，服务器由复杂的类组成，搞定大部分逻辑，bean紧紧是一个对象。
本章主要讲解几种常见的应用设计模式，事务脚本，领域模型，表模块，事务脚本和表模块在现在的开发中已经少见了，大多数开发都是在领域模型中，采用操作脚本，service层厚重，即贫血模型，搞定大部分逻辑，bean实体类里面少有领域逻辑。
转载于:https://my.oschina.net/lohonx/blog/135352