整洁架构中处理外部设备回调是否有优雅的实现方案？

用「核心层自定义抽象 + 薄适配器转译」的方案就可以同时解决依赖侵入和过度设计的问题，具体实现逻辑如下：

第一步：核心层定义业务侧回调抽象 #

完全在你的业务核心层（用例层/领域层）定义一套仅和你的交易业务相关的回调接口，不需要参考任何外部支付API的规则，示例代码：

// 存放在核心业务模块，完全不依赖外部SDK
public interface TransactionProgressListener {
    // 触发输入密码提示
    void onPinRequested();
    // 触发取卡提示
    void onCardRemovalRequested();
    // 交易完成通知
    void onTransactionCompleted(boolean isSuccess, String tip);
}

你的核心交易逻辑仅依赖这个自定义接口，完全感知不到外部支付SDK的存在。

第二步：适配器层实现回调转译 #

将外部支付API要求实现的回调类完全放到支付适配器模块中，这个类仅做「外部SDK回调事件→核心层抽象回调方法」的转译，相当于一个无业务逻辑的转接头：

// 仅存放在支付适配器模块，核心层完全感知不到该类存在
public class PaymentCallbackAdapter implements ThirdPartyPaymentCallback {
    private final TransactionProgressListener coreListener;

    public PaymentCallbackAdapter(TransactionProgressListener coreListener) {
        this.coreListener = coreListener;
    }

    // 实现外部SDK要求的回调方法，做事件转译
    @Override
    public void onEvent(ThirdPartyPaymentEvent event) {
        switch (event.getEventType()) {
            case INPUT_PIN:
                coreListener.onPinRequested();
                break;
            case EJECT_CARD:
                coreListener.onCardRemovalRequested();
                break;
            case TRADE_SUCCESS:
                coreListener.onTransactionCompleted(true, event.getMsg());
                break;
            case TRADE_FAIL:
                coreListener.onTransactionCompleted(false, event.getMsg());
                break;
        }
    }
}

发起交易时，你只需要把这个适配器的实例传给外部支付SDK即可，所有外部SDK的规则都被隔离在适配器层。

方案优势 #

• 无依赖侵入：核心逻辑完全不依赖外部支付SDK的任何定义，符合整洁架构的依赖倒置规则
• 不存在过度设计：适配器层仅包含简单的转译逻辑，代码量极低，维护成本可以忽略
• 测试成本极低：核心逻辑测试时直接mock你自定义的TransactionProgressListener即可，完全不需要引入支付SDK，也不需要适配外部API的规则
• 扩展性强：后续更换支付终端/支付渠道时，仅需要新增对应适配器的转译逻辑，核心业务代码不需要做任何修改

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