一个基于Domain Event的分层架构思考

最近在对之前做过的一个项目进行二期修改。鉴于之前典型的贫血结构，以及Controller--->Service--->DAO模式让代码压力都集中在service层的情况。在参考了网上几篇对象职责和Domain Event的文章后，我也试着捣鼓了一下新的分层模式。贴出来和大家讨论，欢迎拍砖！

【1】层次划分：

①控制层：数据映射、控制转向、业务调用
②业务层：从用户角度出发，看到的系统可以提供的功能接口
③实体层：包含了数据与行为的实体对象
④服务层：从程序内部角度出发，为了完成业务而划分出来的细粒度功能模块
⑤仓储层：对象的构建、缓存、持久化

上面我的说法可能不是很规范,因为DDD也没有仔细的研究，可能大家会对业务和服务层的直至有所疑惑：这里我的想法就是一个从用户角度出发的业务操作，对应到程序内部可能会被划分成多个细粒度的程序操作。

【2】协作关系：

①控制层与业务层：
 ※控制层提供业务层所需的原始，未经封装的数据
 ※控制层提供业务调用
 ※业务层返回给控制层业务出来结果，由控制层决定转向

②业务层与实体层：
 ※业务层在必要时(new，edit，delete等一系列命令操作)，从仓储中加载对象
 ※业务层向实体层对象发出事件通知
 ※业务层接收实体的行为反馈

③实体与服务层：
 ※实体通过“服务注册”的方式，让实体具有“自我数据操纵”的能力
 ※实体接受到业务层的事件通知后，广播给注册的服务提供者
 ※服务层为需要提供服务的实体提供相应的操作功能
 ※实体层中包含了实体逻辑(可以自己处理而不需要依赖其他模块、层次)
 ※服务层中包含了服务逻辑(无法通过一个对象自身完成，涉及到其它对象)

④业务与服务层：
 ※当业务要求是查询要求，或者与特点对象无关时，业务层直接请求服务层
 ※服务层可以看成是对业务层请求的内部实现

⑤服务层与仓储层：
 ※仓储层的对象实体可以是：新建，缓存，从持久化介质中加载
 ※仓储层中包含了构建对象的Builder，否则构建和校验
 ※仓储层中包含了对象的缓存和缓存操作
 ※仓储层中包含了对持久层的访问

⑥实体与仓储层：
 ※仓储层构建的最终对象就是实体，仓储是实体的来源，也是实体最终的去向

下面分为两只情况来阐述协作流程：

【3】增删改请求的协作流程

【4】查询请求的协作流程

【5】疑惑与担忧

 

目前还有几个问题一直困扰着我

①这种分层是否合理？因为我想让对象通过事件来消除和服务层的耦合？
②这种把命令、查询分开来对待的做法会不会令日后的逻辑变得分散而难以维护？
③对于这种分层模式，事务控制应该是在业务层还是服务层？

④缓存与对象构建放在仓储中是否合适？

欢迎大家讨论~~