明月松间照 清泉石上流

先从后端的dao说起吧：
已有项目的开发以及appfuse的开发，都属于传统的开放方式，内部有dao，外部还有service。

这样的开发方式太学院了，每次改动其实影响面很大，要改二个类，两个接口。平时不忙的时候也就算了，项目一紧的话，大家就乱来的了。相当部分都是最外层接口实现类就直接访问了数据库，而不走规范路线。

现在对外提供一个repository的service接口（加载该领域模块的root对象，以便程序利用root对象来游走，ddd推荐的做法），然后内部有一个dao接口，继承该repository接口，提供一些内部使用的额外服务，比如一些数据库查询。接着有一个类继承框架提供的如spring的HiberanteTemplate同时实现dao接口，这样来改动的规模就比较小，一个接口和一个实现类。这个思路和SS2的思路是一样的。

框架数据访问已经提供一些公共的操作简化开发，当然还利用泛型等。此外，Ibatis3.0的设计思路，将是下一步的工作目标。

另外：通过root对象游走访问领域对象，性能可能有点问题。但这是可以接受的，因为从开发的角度看，通常都root下的对象都是和root对象一起出现操作的，不可能单一出现一个root以外的对象来操作以及显示的。

现在就说说Web层：
由于servcie对外都是开放domian model了，不再提供VO对象，免去无谓的copy property操作。而把VO的这部分工作交给自行开发的界面设计工具，因此在设计页面的时候其实已经知道的页面的访问的元素以及对象路径，在设计页面完成后由该设计工具生成VO对象和映射对象。这样VO对象的设计产生，以及property的copy都是工具完成，无须人工干预。

另外Web层采用SWF，除了完整的抽取出流程控制流转逻辑，还完整的封装了对于Request以及Response的数据访问操作。这样一个流程中调用了那些model以及servcie都非常清楚。将来有可能通过工具像规则引擎那样可以提供给业务人员直接使用。同时没有了传统的Control类结构的存在，极大的提高了开发效率问题。

模块边界的处理包括两个部分：
一是行为的边界集成上，比如订单管理模块对财务模块的行为要求。
订单管理模块自行设计它所需要的接口，由一个集成模块提供adapter类，来适配到财务模块合适的service上。这样就解决了旧系统设计现有的问题，旧系统现在都是直接调用财务模块提供的API，这样的做法实际上是把集成工作放在了订单管理模块下。

二是对象的边界集成，是这样做的。
订单明细对象（OrderItem）会关联一个产品对象，不过产品对象是是属于产品模块而非订单模块，对于订单模块只关心id而并不使用对象，但在规则引擎或者界面设计工具这样的集成环境却是需要产品对象的。我们采用代码生成的方式，在订单明细对象上加一个annotation，比如Integration的annotation标识，使用aspectj在编译上enhancement生成的class，使得订单明细对象在集成环境上可以拿到产品对象，这算是一个集成方面。

最后是domain model部分：
一类是类似保险中的保单对象这样的长生命周期对象；

另一类是transaction交易过程的对象，几乎没有生命周期的；

最后一类是request/response对象。这类对象以前没有识别，通常和VO混在一起；但是在IAA中以及电信业的模型是这类对象是独立存在，并被持久化的。
当然他们也是几乎没有生命周期的，request对象建立在增量更新上很有用。

reponse对象目前没有特别用途，依然采用VO处理。

request对象的建立有两个好处。
1. 以前直接更新订单对象，虽然记录了log但是只知道减肥前，减肥后。
2. request对象的第二个好处，可以解决一个业务事务跨越两个物理事务的设计问题。即一个业务请求可以分多次累进完成，比如分两天来处理，每天完成一个部分，但在完成之前，所有操作数据都不生效。在没有持久化request对象前，我们只能把操作的数据写到临时表上。

此外，由于某个领域模块的增量操作通常从一个根对象开始，所依赖的criteria可以从request中加以识别并通过框架提前加载，而service对象的方法接受传递对象而不再关心对象的加载工作；同时也可以通过框架处理基本数据复制工作，这样程序只关心关联对象的操作。这个做法和SS2是一样的，只不过采用的是AOP的处理方式。