谈架构设计中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就是为了标注这种歧义。

哈哈哈，说完了，不知道大家有没有看明白，望得到高人指点。