基于Spring Boot的六边形架构三层设计疑问咨询

疑问1：Ports与use cases作为接口，是否应置于domain层？ #

• 核心要区分端口类型：
  • 被驱动端口（如仓储接口、外部服务调用抽象）：必须放在domain层。这是领域模型依赖的外部能力抽象，领域层只定义自己需要的接口，完全不关心具体实现，保证领域核心的独立性。
  • 驱动端口（即use case接口）：建议放在domain层或application/ports子包。从六边形架构“领域为核心”的思想出发，use case是领域能力的对外暴露，属于领域边界的一部分；若团队习惯将其放在application层也可，只要确保domain层不依赖任何外层代码即可。

疑问2：Adapters作为Ports接口的实现类，是否应置于infrastructure层？ #

• 分类型处理：
  • 被驱动适配器（如JPA实现的仓储、第三方API调用客户端）：必须放在infrastructure层。这类适配器是对接外部资源（数据库、外部服务）的具体实现，属于基础设施范畴，完全隔离在domain层之外。
  • 驱动适配器（如REST控制器、CLI入口）：若你的分层只有三层，可放在infrastructure层；也可以单独拆出adapter层管理，核心是明确它是外部触发领域逻辑的入口即可。

疑问3：关于use case接口的实现 #

3.1 该实现类应置于application层还是infrastructure层？ #

• 必须放在application层。use case的实现是协调领域模型与外部资源的编排逻辑——比如注册用户时，先调用领域对象做参数校验、生成实体，再调用仓储接口保存。这类逻辑既不属于领域核心（领域核心是实体的业务规则），也不属于基础设施（基础设施是具体实现），放在application层作为中间协调者最合理。

3.2 它是否等价于Spring中标注@Service注解的Service类？ #

• 可以等价，但有边界。Spring的@Service用于标记业务逻辑组件，而use case实现类恰好承担了业务流程编排的角色，因此可以给它添加@Service注解交由Spring管理生命周期。但要注意：不要把领域核心规则放到这个类里，它只负责流程协调，真正的业务逻辑必须封装在domain层的实体、值对象中。

3.3 它应调用作为属性的Ports实现类（Adapters），还是反之？ #

• 必须是use case实现类调用Ports实现类。六边形架构的核心是依赖倒置原则：高层模块（application层的use case实现）依赖抽象（Ports接口），底层模块（infrastructure层的Adapters）实现抽象。因此是use case注入Ports接口的实现（如仓储适配器）并调用其方法，而非反过来。这样domain层和application层完全不依赖具体的基础设施实现，只依赖抽象，保证了架构的可扩展性。

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