标签:仓储 src 指点 nbsp 设计 epo ons ddd strong
首先,描述一下我的业务场景及项目分层结构,非标准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就是为了标注这种歧义。
哈哈哈,说完了,不知道大家有没有看明白,望得到高人指点。
标签:仓储 src 指点 nbsp 设计 epo ons ddd strong
原文地址:https://www.cnblogs.com/lxz-blog/p/12036697.html