清洁架构原则下，用例能否依赖多领域仓库？附学生选课场景问询

这种做法是否违反清洁架构原则？ #

不违反，但要注意依赖的抽象性和方向是否符合架构要求。

清洁架构的核心规则是内层（实体、用例层）不依赖外层（接口适配器、基础设施层），所有依赖必须从外层指向内层——也就是说用例可以依赖自己层定义的抽象接口，而不是具体的数据库实现类。

把读取学生/课程的抽象接口作为用例的依赖，本质上是让用例负责执行“关联操作必须基于存在的学生和课程”这一业务规则，这属于用例层的职责范畴，完全符合清洁架构的设计思想。

正确的处理方式 #

1. 定义用例层的抽象端口
   在AddStudentToCourseUsecase所在的用例层，定义三个抽象接口：

   • ReadStudentByIdPort：包含findById(studentId)方法，返回学生或空值
   • ReadCourseByIdPort：包含findById(courseId)方法，返回课程或空值
   • AddStudentToCoursePort：包含link(studentId, courseId)方法，负责执行关联操作

2. 用例依赖抽象端口实现校验逻辑
   AddStudentToCourseUsecase的构造函数接收上述三个抽象端口作为依赖，执行逻辑时：

   • 先调用ReadStudentByIdPort和ReadCourseByIdPort查询对应实体
   • 若任意实体不存在，直接返回“学生/课程不存在”的错误
   • 若两者都存在，调用AddStudentToCoursePort完成关联操作

3. 外层适配器实现抽象端口
   在基础设施层（如数据访问层），针对每个抽象端口编写具体实现：

   • 比如JpaStudentReader实现ReadStudentByIdPort，通过JPA查询数据库
   • JpaCourseReader实现ReadCourseByIdPort，同理对接数据库
   • JpaStudentCourseLinker实现AddStudentToCoursePort，维护关联表

避坑提示 #

不要让用例直接依赖具体的数据库实现类（比如JpaStudentRepository），必须通过用例层的抽象接口做隔离，否则会破坏清洁架构的依赖方向，导致用例层和基础设施层耦合。

另外，不要依赖数据库的外键约束来触发错误——这种方式把业务校验逻辑转移到了外层框架，不符合清洁架构“业务规则集中在内层”的要求，一旦更换数据库或框架，校验逻辑可能失效。

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