大神，你好，我明白你的意思。但是最终的实现还是得落到表上噻。现在我是想通过代码来实现理解，所以我建了个基本的架构：基础设施层、领域层、应用层、展示层。比如一个简单的 修改角色及其对应的角色权限功能，在实现这个的时候该怎么设计应用服务和领域服务呢？不知道这个例子恰不恰当？领域服务是实现业务逻辑噻，但是一个应用服务又是一个工作单元，是不是就是在领域层放两个仓储（修改角色、修改角色权限），然后在应用层调用这两个，来实现数据的一致。。

@众生少两千: 这里我理解的话你所谓的角色是个聚合，而权限可能是个值对象（就你的描述实在看不出来权限这个本身还有什么可变化的余地，比如添加这个操作的权限。不太明白你修改角色和角色权限有什么区别），如果是这样其实只需要一个仓储就可以了，甚至都不需要用unit of work

关于unit of work 你看下ms的这篇文章

https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

关于应用服务，它其实是很薄的一层，有时候只是完成最基础的验证逻辑，有时候可能需要组合多个领域服务完成跨领域对象的一些操作。而领域服务则承载着域内所有的业务逻辑。