我正在为我的应用程序遵循 DDD 架构。我有应用层、域层和数据访问层（存储库）。假设我在我的应用程序中有 3 个角色：管理员、主管、代理。每个角色都应该访问分配给自己的数据。所以问题是，我是否应该放置查询逻辑以便按存储库中的角色过滤数据，例如
var query = dataContext.Order.Where(...);
if(userRole = "admin")
query =.... filter by admin
If(usrRole = "supervisor")
query =....
return query.ToList();
我认为与业务逻辑相关的逻辑应该放在领域层。但我还没有清除这一点。你们能帮我解决这个问题吗？
到目前为止，我读过的最好的解释是来自Wrox 出版的Patterns, Principles and Practices Of Domain-driven Design的解释。下图类似于核心思想。
所有依赖都指向内部，因此领域模型不依赖其他任何东西，并且不知道其他任何东西。其中它是纯粹的，并且可以专注于重要的领域的语言。
应用程序层（包含应用程序服务）公开了一个用例 API，并使用涉及的域服务编排请求。因此，应用服务中的代码是程序化的，而领域模型中的代码通常要丰富得多。也就是说，如果域足够复杂以保证它的存在。
但是我跑题了，回答你的问题，应用层公开了基础设施实现的接口（例如存储库模式）。也是应用层知道如何查询数据（通过使用这个接口），并根据角色进行过滤。
领域模型应该只接收过滤后的集合，并且只关注一件事，处理数据。
为了完整性，DDD 允许许多架构，只要域没有依赖关系。虽然我觉得它最容易掌握，但这样想。
存储库表示聚合根的集合。因此，当您想要检索一些聚合或聚合列表时，您需要在存储库上执行业务操作，这是您可以去的地方。
在您的情况下，我想您有某种用户聚合，我可以在您的存储库中想到以下方法： findById(UserId id) findByRole(UserRole role)
而findById()将只返回一个聚合，而findByRole()返回一个聚合列表。
始终牢记仅从相应的存储库返回完整的聚合对象，并在域层中定义存储库接口，同时将存储库实现放入基础架构层。
可能有理由不从存储库返回完整的聚合，例如创建摘要或仅计算数量，例如具有特定标准的用户数量。但请记住，在这种情况下只返回不可变对象，这些对象是只读的。但是这些信息应该只在大多数情况下与执行业务操作相关。