企业应用架构模式——笔记（1）

企业应用架构模式学习笔记

2008-1-27

第一部分 表述

1       分层

1.1    三个基本层次

三层架构：

表现层：表现逻辑处理用户与软件间的交互。主要职责是：

ü         向用户显示信息

ü         把从用户那里获得的信息解释成领域层或数据源层上的各种动作。

数据源层：数据源逻辑主要关注与其他系统的交互，这些系统将代表应邀完成相关的任务。主要的数据源逻辑就是数据库，它的主要职责是存储持久数据。

领域层：领域逻辑（业务逻辑），它就是应用必须做的所有领域相关的工作：

ü         根据输入数据或已有数据进行计算

ü         对从表现层输入的数据进行验证

ü         根据从表现层接收的命令来确定应该调度哪些数据源逻辑。

 

三层的关系：领域层是核心！表现层是系统对外提供服务的外部接口；数据源层是系统使用外部服务的接口。

零雨其蒙批注：这段话实在是经典，表现层作为对外提供服务的接口，指明了外部如何使用该系统的契约，这样领域层可以作为Web Service暴露给外部，可以是REST风格的服务接口，抑或作为另一个系统的数据源。而数据源层作为领域层访问外部服务的接口，指明了该系统如何使用其它服务的契约，这些服务就可能是数据库服务，消息服务，甚至是另一个可以提供数据的系统，我想这层之下的层次叫做EIS的原因吧。     这也恰恰提醒我们，表现层接口和数据源层（我还是觉得叫数据访问层比较好）接口并不直接相关，因此在设计时不要将这两个接口进行简单的设计映射，表现层接口的契约与数据源层接口的契约简单对应会造成系统不稳定，数据访问层的变动将导致表现层接口的变动。另外，由于要记住，它们是为不同目的设计的！

分层结构依赖原则：领域层和数据源层绝对不要依赖于表现层。也就是说，在领域层和数据源层的代码中，不要出现调用表现层代码的情况。

 

区分逻辑层次的是否划分正确的简单测试原则：层次替换修改原则（注：我自己给起的名字）——假想向系统中增加一个完全不同的新层，例如为Web应用增加一个命令行界面层。如果这个过程中，发现需要重复实现某些功能，则说明可能有一些本应该在领域层实现的逻辑，现在在表现层实现了。类似的，你可以假想一下，将后台数据库更换成XML文件格式，看看情况又如何？

2       组织领域逻辑

事务脚本模式与领域模型模式。

范例：

核心问题是：对于同一给定的合同，不同种类的产品有不同的收入确认算法。计算收入确认的方法中必须先确定给定合同中产品的种类，然后应用正确的算法，之后再创建相应的收入确认对象[U1] （RevenueRecognition）来保存计算结果。

 

使用事务脚本计算收入确认

a Recognition Service：确认服务

calculateRecognitions(contractID)：根据合同（contract）ID计算确认

findContract(contractID)：向数据入口发送“查找合同”消息，根据合同ID查找合同，返回合同结果集

insert revenue recognitions：插入收入确认。

 

使用领域模型计算收入确认

 

     利用了典型的策略模式（GoF），将对于不同产品的确认策略分离出来，以实现对于不同产品采取不同的计算确认策略。

class Contract{

 

   private Product product;

 

   public void setProduct(Product product){

        this. product= product;

}

 

public Product getProduct(){

     return this. product;

}

   public void calculateRecogntions(){

        getProduct().calculateRecogntions(this);

}

}

 

class Product{

 

   private RecogntionStrategy recogntionStrategy;

 

   public void set RecogntionStrategy (RecogntionStrategy recogntionStrategy){

        this. recogntionStrategy = recogntionStrategy;

}

 

public RecogntionStrategy getRecogntionStrategy (){

     return this. recogntionStrategy;

}

   public void calculateRecogntions(Contract contract){

        getRecogntionStrategy ().calculateRecogntions (contract);

}

}

2.1    服务层

概念：处理领域逻辑的常见方法是将领域层再细分成两层。服务层独立出来，置于底层的领域模型或表模块之上。

职责：表现逻辑与领域层的交互完全通过服务层，就好像应用程序的API一样。服务层是放置事务控制和安全等功能的好场所。

组成：最小化情况下，服务层只是一个外观，所有实际的行为都在下层的对象中，服务层所做的只是将上层调用传递到更低层。此时，服务层提供一个更易于使用的API，因为它的方法通常根据用例来组织。该方式是Fowler最为推崇的方式。另外还有将服务层实现为一个事务脚本或使用控制器-实体模式。

3       映射到关系数据库

3.1    架构模式

讲了几种入口（Gateway）模式后，Fowler指出：一种更好的方法是把领域模型和数据库完全独立，可以让间接层完成领域对象和数据库表之间的映射。这个数据映射器处理数据库和领域模型之间所有的存取操作，并且允许双方都能独立变化。

零雨其蒙注解：目前采用Hiberante之类的O/RM框架就是实现该模式。

另外，Fowler不推荐把入口（Gateway）用作领域模型的首选持久化机制。

即使使用数据映射器作为首选持久化机制，还是可以使用数据入口来封装被视为外部接口的表或者服务。

零雨其蒙注解：目前采用DAO模式是更好的表述。

 

 [U1]相当于《结算方式确认通知书》？？？