最近在对之前做过的一个项目进行二期修改。鉴于之前典型的贫血结构，以及Controller--->Service--->DAO模式让代码压力都集中在service层的情况。在参考了Banq写的几篇对象职责和Domain Event的文章后，我也试着捣鼓了一下新的分层模式。贴出来和大家讨论，欢迎拍砖！
【1】层次划分：
①控制层：数据映射、控制转向、业务调用
②业务层：从用户角度出发，看到的系统可以提供的功能接口
③实体层：包含了数据与行为的实体对象
④服务层：从程序内部角度出发，为了完成业务而划分出来的细粒度功能模块
⑤仓储层：对象的构建、缓存、持久化
上面我的说法可能不是很规范,因为
DDD也没有仔细的研究，可能大家会对业务和服务层的直至有所疑惑：这里我的想法就是一个从用户角度出发的业务操作，对应到程序内部可能会被划分成多个细粒度的程序操作。
【2】协作关系：
①控制层与业务层：
※控制层提供业务层所需的原始，未经封装的数据
※控制层提供业务调用
※业务层返回给控制层业务出来结果，由控制层决定转向
②业务层与实体层：
※业务层在必要时(new，edit，delete等一系列命令操作)，从仓储中加载对象
※业务层向实体层对象发出事件通知
※业务层接收实体的行为反馈
③实体与服务层：
※实体通过“服务注册”的方式，让实体具有“自我数据操纵”的能力
※实体接受到业务层的事件通知后，广播给注册的服务提供者
※服务层为需要提供服务的实体提供相应的操作功能
※实体层中包含了实体逻辑(可以自己处理而不需要依赖其他模块、层次)
※服务层中包含了服务逻辑(无法通过一个对象自身完成，涉及到其它对象)
④业务与服务层：
※当业务要求是查询要求，或者与特点对象无关时，业务层直接请求服务层
※服务层可以看成是对业务层请求的内部实现
⑤服务层与仓储层：
※仓储层的对象实体可以是：新建，缓存，从持久化介质中加载
※仓储层中包含了构建对象的Builder，否则构建和校验
※仓储层中包含了对象的缓存和缓存操作
※仓储层中包含了对持久层的访问
⑥实体与仓储层：
※仓储层构建的最终对象就是实体，仓储是实体的来源，也是实体最终的去向
下面分为两只情况来阐述协作流程：
【3】增删改请求的协作流程
【4】查询请求的协作流程
【5】疑惑与担忧
①这种分层是否合理？因为我想让对象通过事件来消除和服务层的耦合？
②这种把命令、查询分开来对待的做法会不会令日后的逻辑变得分散而难以维护？
③在仓储的构建过程中，有可能需要调用服务层逻辑，会不会造成服务<--->仓储的双向依赖而耦合？
写了很多~~~也有劳大家费心看看。实在不想再回到贫血模型的日子啦
-------------------------------------------------------------
生活就像打牌，不是要抓一手好牌，而是要尽力打好一手烂牌。
posted on 2010-03-23 17:05
Paul Lin 阅读(1573)
评论(0) 编辑 收藏 所属分类:
架构与性能