六边形架构中Ports/Adapters模式的具体优势及直接调用服务的差异

首先是Ports/Adapters模式的典型实现代码：

@RestController
private class OrderController {

    private final CreateOrderPort createOrderPort;
    
    @PostMapping
    void createOrder(String customerId) {
        createOrderPort.createOrder(customerId);
    }
}


private class KafkaConsumer {

    private final CreateOrderPort createOrderPort;
    
    @PostMapping
    public void createOrder(CreateOrderEvent event) {
        createOrderPort.createOrder(event.getCustomerId());
    }
}

public interface CreateOrderPort {
    void createOrder(String customerId);
}

@Service
public class CreateOrderService implements CreateOrderPort {
    public void createOrder(String customerId){
        orderRepository.save(new Order(customerId));
    }
}

问题 #

我想了解此处使用接口CreateOrderPort的具体优势是什么？如果Kafka消费者与OrderController直接依赖CreateOrderService会有哪些差异？

以下是直接依赖服务的实现代码：

@RestController
private class OrderController {

    private final CreateOrderService createOrderService;
    
    @PostMapping
    void createOrder(String customerId) {
        createOrderService.createOrder(customerId);
    }
}


private class KafkaConsumer {

    private final CreateOrderService createOrderService;
    
    @PostMapping
    public void createOrder(CreateOrderEvent event) {
        createOrderService.createOrder(event.getCustomerId());
    }
}

@Service
public class CreateOrderService{
    public void createOrder(String customerId){
        orderRepository.save(new Order(customerId));
    }
}

即便直接调用服务，我们似乎仍能实现技术细节（适配器或边界）与业务核心（领域层）的分离，且服务变更不会影响技术层，那两者的差异究竟在哪？

核心差异与接口Port的优势 #

1. 业务规则的独立性与反向依赖

使用CreateOrderPort接口时，业务核心（CreateOrderService）定义自己对外暴露的能力边界，完全符合依赖倒置原则：高层模块（业务逻辑）不依赖低层模块（具体实现），两者都依赖抽象。

• 若直接依赖CreateOrderService，外部调用者会绑定到具体业务实现类上。未来如果业务逻辑拆分（比如拆分为CreateStandardOrderService和CreateVipOrderService），所有调用者都要修改依赖注入代码，甚至调整调用逻辑。
• 用接口的话，只需新增实现类并通过配置切换，外部调用者完全无需改动，因为它们依赖的是抽象的能力约定。

2. 测试的灵活性

• 针对OrderController或KafkaConsumer做单元测试时，依赖CreateOrderPort可以轻松用Mock实现替代真实服务，不需要引入数据库等外部依赖，测试更隔离、速度更快。
• 直接依赖CreateOrderService的话，要么需要Mock服务内部的orderRepository，要么得启动完整Spring上下文并准备测试数据，测试成本更高、耦合性更强。

3. 业务能力的抽象与复用

CreateOrderPort定义的是**“创建订单”这个业务动作的抽象**，而非某个具体服务的实现。未来如果新增技术适配器（比如RabbitMQ消费者、CLI工具）需要调用该能力，只需依赖这个接口即可，无需关心背后的业务逻辑由哪个服务实现。

• 直接依赖服务类的话，每个新调用者都要绑定到CreateOrderService上，一旦服务类结构变化（比如新增方法、修改构造函数），所有调用者都可能受影响。

4. 架构演进的自由度

当业务复杂度提升时，接口Port可作为业务能力的契约，帮助你在不影响外部适配器的前提下重构内部业务逻辑：

• 比如引入领域事件、调整事务管理，或者替换底层存储实现，只要保持CreateOrderPort的接口契约不变，所有外部调用者都无需感知这些变化。
• 直接依赖服务类的话，业务逻辑的任何内部调整都可能“泄漏”到外部调用层，比如CreateOrderService新增参数时，所有调用它的Controller、消费者都得跟着修改。

关于“直接调用也能分离”的误区 #

你提到直接调用服务似乎也能分离技术层和业务层，但这种分离是脆弱的：

• 技术层（Controller、KafkaConsumer）直接依赖的是业务层的具体实现类，而非抽象的业务能力。一旦业务层实现类发生非功能性变化（比如修改访问权限、调整Bean作用域），技术层可能被迫调整。
• 这种模式下，业务层无法自主定义对外的能力边界，而是被外部调用者“牵着鼻子走”，违背了Ports/Adapters模式中“业务核心独立于外部技术”的设计初衷。

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