基于整洁架构优化同逻辑类：如何重构canDoX方法？

按照整洁架构“核心业务逻辑独立于基础设施层，依赖方向向内”的要求，我们可以通过以下步骤重构canDoX方法：

1. 把业务规则从数据实体中彻底抽离 #

canDoX的判断逻辑属于核心业务规则，不应该和数据库映射实体绑定。我们可以把它放到一个纯业务类里，这个类不依赖任何ORM实体，只负责维护业务判断逻辑：

// 核心领域类：只处理业务规则，和数据持久化完全解耦
public class MyDataBusinessRules {
    public static boolean canDoX(String statusA, String statusB) {
        return "z".equals(statusA) && "y".equals(statusB);
    }
}

2. 让数据实体类复用统一的业务规则 #

原来的MyData和新建的MyDataWithHalfOfFields只需要做数据载体，直接调用业务类的方法即可，不用自己实现判断逻辑：

修改后的MyData #

class MyData {
    String statusA;
    String statusB;
    String statusC;
    ...
    Something field20;

    boolean canDoX() {
        return MyDataBusinessRules.canDoX(this.statusA, this.statusB);
    }
}

修改后的MyDataWithHalfOfFields #

class MyDataWithHalfOfFields {
    String statusA;
    String statusB;
    String statusC;
    ...
    Something field10;

    boolean canDoX() {
        return MyDataBusinessRules.canDoX(this.statusA, this.statusB);
    }
}

3. 进阶：用依赖反转强化架构分层 #

如果想更严格贴合整洁架构的依赖反转原则，可以定义一个抽象接口，描述业务规则需要的属性，让两个实体类实现该接口，业务规则类只依赖这个抽象接口：

定义领域层抽象接口 #

public interface StatusForXProvider {
    String getStatusA();
    String getStatusB();
}

实体类实现接口 #

class MyData implements StatusForXProvider {
    String statusA;
    String statusB;
    // 其他字段...

    @Override
    public String getStatusA() {
        return statusA;
    }

    @Override
    public String getStatusB() {
        return statusB;
    }

    boolean canDoX() {
        return MyDataBusinessRules.canDoX(this);
    }
}

class MyDataWithHalfOfFields implements StatusForXProvider {
    String statusA;
    String statusB;
    // 其他字段...

    @Override
    public String getStatusA() {
        return statusA;
    }

    @Override
    public String getStatusB() {
        return statusB;
    }

    boolean canDoX() {
        return MyDataBusinessRules.canDoX(this);
    }
}

更新业务规则类 #

public class MyDataBusinessRules {
    public static boolean canDoX(StatusForXProvider provider) {
        return "z".equals(provider.getStatusA()) && "y".equals(provider.getStatusB());
    }
}

重构后的好处 #

• 避免重复代码：业务逻辑只维护一份，两个实体类复用同一套规则。
• 符合整洁架构：核心业务规则不依赖外层的数据库实体，所有依赖都指向领域层内部。
• 扩展性强：以后新增类似的裁剪实体类，只要实现StatusForXProvider接口，就能直接复用canDoX逻辑，不用重复写判断。

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