首先，描述一下我的业务场景及项目分层结构，非标准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就是为了标注这种歧义。
哈哈哈，说完了，不知道大家有没有看明白，望得到高人指点。
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论