谈架构设计中DDD思想的运用
首先,描述一下我的业务场景及项目分层结构,非标准ddd(其实我不觉得有标准),只是思考的时候有带入ddd思想。
业务场景:这是一个erp系统对中台提供的接口项目,仓储操作大多都是存储过程去完成的。
项目结构,如图:
webapi层:这个不用多说了,入口。
dto层:增加数据传入传出对象,和领域model、实体model区分。(要不要围绕领域model或从现有系统中提取领域model看实际业务情况,拿我目前这个项目来说,得不偿失。)
services层:业务服务层(可以命名成bizservices区分),主要写一些业务逻辑,然后调用领域服务层domainservices(如果有的话),如果没有,则直接调用仓储服务,进行持久化操作。
repository层:打算用dapper进行持久化操作,对外提供repositoryservice。我这里比较特殊,下面讲。
融合了一部分ddd思想后,项目结构和流程本来应该是这样:request→webapi→dto→bizservices→domainservices→repositoryservice→dto→response。
一个request对应一个bizservices可能对应多个domainservices可能对应多个repositoryservice
实际是这样的:request→webapi→dto→bizservices→repositoryservice/.domainservice→dto→response。
那么,问题就来了:
因为domainservices应该做的聚合repository.service的操作实际都在存储过程中进行了,但repository.service同时完成了repository.service和domainservices一起干的事情,产生了越界,这个不管我把domainservices拿出去放外面一层,实际情况都如上所述。
症结就是存储过程干了domainservices的事情,不要跟我说把存储过程的事情拿出来重新写一遍,你以为面对不知道有没有1000个的存储过程我没认真想过嘛,所以repository.service.domainservices就是为了标注这种歧义。
哈哈哈,说完了,不知道大家有没有看明白,望得到高人指点。
上一篇: Python 基础:入门必备知识
下一篇: 巧用 CSS 实现酷炫的充电动画