当前位置:网站首页>讨论:这样基于Domain Event的分层是否合理?

讨论:这样基于Domain Event的分层是否合理?

2021-05-04 15:44:50 解道jdon

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

【1】层次划分:

①控制层:数据映射、控制转向、业务调用

②业务层:从用户角度出发,看到的系统可以提供的功能接口

③实体层:包含了数据与行为的实体对象

④服务层:从程序内部角度出发,为了完成业务而划分出来的细粒度功能模块

⑤仓储层:对象的构建、缓存、持久化

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

【2】协作关系:

①控制层与业务层:

※控制层提供业务层所需的原始,未经封装的数据

※控制层提供业务调用

※业务层返回给控制层业务出来结果,由控制层决定转向

②业务层与实体层:

※业务层在必要时(new,edit,delete等一系列命令操作),从仓储中加载对象

※业务层向实体层对象发出事件通知

※业务层接收实体的行为反馈

③实体与服务层:

※实体通过“服务注册”的方式,让实体具有“自我数据操纵”的能力

※实体接受到业务层的事件通知后,广播给注册的服务提供者

※服务层为需要提供服务的实体提供相应的操作功能

※实体层中包含了实体逻辑(可以自己处理而不需要依赖其他模块、层次)

※服务层中包含了服务逻辑(无法通过一个对象自身完成,涉及到其它对象)

④业务与服务层:

※当业务要求是查询要求,或者与特点对象无关时,业务层直接请求服务层

※服务层可以看成是对业务层请求的内部实现

⑤服务层与仓储层:

※仓储层的对象实体可以是:新建,缓存,从持久化介质中加载

※仓储层中包含了构建对象的Builder,否则构建和校验

※仓储层中包含了对象的缓存和缓存操作

※仓储层中包含了对持久层的访问

⑥实体与仓储层:

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

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

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

控制层捕获请求,并决定由那个业务层对象处理

|---> 业务层需要构建/或者单个实体

|---> 从仓储中新建(insert)或者从缓存中加载(edit,delete),并返回实体,注册服务

|---> 向实体对象发出一个事件通知(save, update, delete)

|---> 实体对象遍历自身已注册的服务,广播该事件消息

|---> 服务层处理该事件,调用仓储层

|---> 仓储层执行持久化操作,并返回结果

|---> 接收事件处理结果,并返回给控制层

|---> 根据业务层结果,决定转向

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

控制层捕获请求,并决定由那个业务层对象处理

|---> 业务层直接请求服务层(因为此时请求和单个实体无关)

|---> 服务层处理请求逻辑,并调用仓储层

|---> 仓储层可以从缓存中取,或者从持久化介质中取,并返回

|---> 接收查询结果,并返回给控制层

|---> 根据业务层结果,决定转向

【5】疑惑与担忧

①这种分层是否合理?因为我想让对象通过事件来消除和服务层的耦合?

②这种把命令、查询分开来对待的做法会不会令日后的逻辑变得分散而难以维护?

③在仓储的构建过程中,有可能需要调用服务层逻辑,会不会造成服务<--->仓储的双向依赖而耦合?

写了很多~~~也有劳大家费心看看。实在不想再回到贫血模型的日子啦

[该贴被pengpenglin于2010-03-23 16:37修改过]



版权声明
本文为[解道jdon]所创,转载请带上原文链接,感谢
https://www.jdon.com/38319

随机推荐