Clean Architecture中权限校验的数据获取位置咨询

背景 #

在Clean Architecture架构里新增PermissionsChecker权限校验层，权限判断依赖两部分数据：数据库存储的用户权限、领域对象的状态，目前已实现数据库适配器。

1. 是否在使用例层获取数据并传递给PermissionsChecker？ #

这是完全符合Clean Architecture规则的优先方案。

• 使用例层的核心职责就是协调数据获取与业务逻辑，它可以通过数据库端口（抽象接口，而非具体适配器）获取用户权限数据，同时拿到待校验的领域对象状态，再将这两类数据传递给PermissionsChecker。
• 优势：PermissionsChecker只需专注于权限校验逻辑，不依赖任何外部组件，测试时直接传入模拟的用户权限与领域对象即可，无需依赖数据库，可测试性极强。
• 注意：使用例层必须通过端口获取数据，不能直接调用数据库适配器，这才是依赖倒置原则的正确实践，确保内层不依赖外层的具体实现。

2. 是否在权限层获取数据？ #

不推荐这种方案。

• 如果PermissionsChecker直接依赖数据库端口获取用户权限，会打破Clean Architecture的依赖方向：权限校验层属于业务逻辑内层，不应直接依赖外层的端口（哪怕是抽象端口）。同时这会导致权限层职责混杂，既要处理校验逻辑又要负责数据获取，违反单一职责原则。
• 弊端：测试时需要模拟数据库端口，成本更高；后续修改数据获取逻辑时，必须同步调整权限校验层，耦合度太高，维护难度大。

3. 其他可行方案：将权限校验逻辑内聚到领域层 #

如果权限规则与领域对象的状态强关联，可以尝试这种思路：

• 让领域对象自身封装状态相关的权限判断逻辑，比如给Order类新增canBeEditedBy(UserPermissions)方法，专门判断自身状态是否允许该用户操作。PermissionsChecker作为领域服务，负责整合用户权限（来自数据库）与领域对象的状态判断，完成最终校验。
• 流程示例：使用例层通过数据库端口获取用户权限并转换为UserPermissions领域对象，再拿到目标领域对象，将两者一起传入PermissionsChecker执行校验。
• 变种优化：直接将用户权限包装为UserPermissions领域对象，使用例层负责从数据库适配生成该对象，PermissionsChecker仅与领域对象交互，彻底脱离外部依赖。

总结最优方案 #

优先选择方案1结合领域内聚的思路：

1. 使用例层通过数据库端口获取用户权限，转换为UserPermissions领域对象；
2. 获取待校验的领域对象；
3. 将UserPermissions与领域对象传入PermissionsChecker执行校验；
4. PermissionsChecker仅保留纯校验逻辑，无任何外部依赖，保证高内聚、低耦合。

内容的提问来源于stack exchange，提问作者Symonen