六边形架构（Hexagonal Architecture）中仓储接口应放在领域层还是应用层？

首先给出明确结论：遵循六边形架构（端口-适配器模式）核心设计原则的前提下，仓储接口默认应当放在领域层。
之所以会出现两种放置方式都看似合理的情况，本质是混淆了两类不同定位的仓储接口的职责：

仓储接口放领域层的逻辑 #

六边形架构最核心的规则是内层不依赖外层，外层只依赖内层的抽象定义，领域层作为最核心的内层，承载了所有业务规则，不应该依赖任何外层的实现或定义。
仓储是领域层用来获取、持久化聚合根的依赖，它的方法定义、入参出参规则完全是为领域逻辑服务的：比如领域服务需要调用OrderRepository.GetValidOrderByUserId()来完成订单创建的前置校验，这个方法的命名规则、返回的聚合根结构、参数要求都和领域逻辑强绑定，接口定义自然要放在领域层。基础设施层的仓储实现只需要实现领域层定义的这个接口即可，领域层完全不需要感知具体的实现细节。

什么情况下仓储接口会放在应用层 #

你看到的放在应用层的仓储接口，本质是面向应用用例的查询类接口，不属于领域层面的仓储定义：这类接口通常用来做跨聚合的联合查询、直接返回前端需要的DTO结构，不需要被领域层调用，只服务于应用层的用例逻辑，和领域规则无关，所以会被放在应用层。

两种放置方式的核心区别 #

• 依赖逻辑不同：放在领域层的仓储接口，是应用层、基础设施层依赖领域层的抽象，符合依赖倒置原则；放在应用层的仓储接口如果要被领域层调用，会让领域层反向依赖应用层，直接破坏架构的依赖规则。
• 变更触发逻辑不同：领域层的仓储接口只有在领域规则调整时才会变更，比如新增了订单校验规则需要新的查询条件，才会调整接口定义；应用层的仓储接口变更是因为上层用例或者前端展示需求调整，和领域逻辑没有关联。
• 复用性不同：领域层的仓储接口是领域上下文的通用抽象，同一个域下的所有应用服务都可以复用；应用层的仓储接口通常只服务于特定用例，复用性极低。

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