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

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

【1】层次划分：

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

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

【2】协作关系：

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

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

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

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

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

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

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

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

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

【5】疑惑与担忧

 

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

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

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

欢迎大家讨论~~

 

发表下我的看法：
1.这种分层显得更清晰。尤其是业务层和服务层分开。服务器层更加应该侧重实体对象的服务功能，比如添加一个订单；业务层则更面向表现层的需求。比如用户可以同时添加1个或者多个订单。展示的方式不同，添加订单的业务操作就可能不一样。
2.我自己现在都是用一个查询service来完成所有查询操作的。
3.应该放在业务层。就像我上面说的，一次添加多个订单，可能是要求保证数据完整性的。一个业务可能需要好几个服务来完成。
4.缓存肯定是放在仓储中的。至于对象的创建，和你有点不太一样。我现在是在表现层通过dto的方式，将数据传给service，在service中完成实体对象的创建，再将dto中的数据赋值给实体对象。我感觉这样有一个最大的好处就是对表现层简单了，他只用管理dto对象，不用关心实体对象，也屏蔽了实体对象的实现方式。比如你要修改一个订单，如果用在表现层操作实体对象，那么表现层这时就必须去服务层先load这个实体对象，然后修改值，再传给服务器层update。这实际上load实体对象是没有必要的。如果我用dto，那么就在表现层直接new一个dto对象，设置好值以后传给服务层，这时候服务器再来update实体对象。而且服务层针对dto进行服务，感觉有点别扭。如果加上一个业务层，就更好了，业务层针对dto对象提供业务服务，服务层针对实体对象提供服务。当然这样多引入一层，编码上就变得更麻烦了。呵呵

强烈支持业务层和服务层分开的想法，业务层和服务层应该分别针对业务逻辑和实现逻辑，彼此独立，千万不要彼此交叉。而且service的力度最好能稍微小一点，方便业务层组合多个service来实现新的业务逻辑。

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

这里的实体层买有看明白，你说的应该是一些和实体相关的value object或者说javabean吧？这个应该不算是层吧？

层是分了好多,服务是无状态的,它不涉及业务回逻辑,是为了分担领域对象的职责而出现的.因为这些职责不是实体,也不是值对象应该拥有的.
这三个领域对象是模型的核心.
实体作为了聚合根是一次性装载全部属性(包括聚合的其它值对象或实体),这个通过工厂处理,而到存储里找到相应的对象.
添加,删除这肯定是要和数据库关联的.之前看到一些是将查询和添加分开.添加不经过存储添加,而是添加后再放到存储里.而查询所有都经过它.
书里说对数据库或其它存储介质的访问都通过Repository来处理 .不过事务确实比较麻烦.如果 在这里实现事务处理,当外界服务调用时可能跨越了多个实体的改变,应该如何处理呢?
也许是OO思想还差远了,我还不能处理.

看不太明白。。能否上个代码看看，是什么样写的

中间层细分为业务层和服务层，实际应用的时候怎么有效区分呢？会不会导致这两层混乱？

实用就好了，没有必要生搬硬套。

难不成楼主的二次维护就是要把一期工程的工作全部推倒重来？不要为了DDD而DDD

层次分的很清楚，不过楼主这样分的目的是什么，如果是为了分担service层，那可能就要考虑部署的问题，将业务层和service层进行分开部署吗？是实际上业务层与service层的主要区别就是是否可公用。但并不能分担服务器的压力，因为往往业务层与服务层部署在同一台服务器上，很难分开部署。该种分层的结构是合理的，事物处理一定要放在业务层，控制层不可直接调用服务层，服务层的目的是为了给业务层提供服务。实体层的设计可以详细一些。