Why COLA 3.0 Ditches Complexity: An Ockham’s Razor‑Driven Redesign

Background

COLA (Component Oriented Lightweight Architecture) aims to provide a simple, reproducible, understandable, and controllable set of guidelines for application architecture. The author found that COLA still suffered from unnecessary complexity and performed an upgrade without adding new features, focusing on removing concepts and functions.

Motivation – Ockham’s Razor

The upgrade is driven by Ockham’s razor: “Do not multiply entities without necessity.” The principle is explained with analogies (the emperor’s new clothes, geocentric vs heliocentric models) to illustrate that the simplest solution is often the most correct.

Design “Twists” in Existing Systems

Complex designs arise from unclear boundaries, over‑design for flexibility, and excessive layering, which increase cognitive load and maintenance cost.

Example: Pipeline vs. Ockham‑Compliant Code

Original pipeline style code (shown below) splits a business operation into many small steps, but adds unnecessary indirection.

public class CreateCSPUExecutor {
    @Resource private InitContextStep initContextStep;
    @Resource private CheckRequiredParamStep checkRequiredParamStep;
    @Resource private CheckUnitStep checkUnitStep;
    @Resource private CheckExpiringDateStep checkExpiringDateStep;
    @Resource private CheckBarCodeStep checkBarCodeStep;
    @Resource private CheckBarCodeImgStep checkBarCodeImgStep;
    @Resource private CheckBrandCategoryStep checkBrandCategoryStep;
    @Resource private CheckProductDetailStep checkProductDetailStep;
    @Resource private CheckSpecImgStep checkSpecImgStep;
    @Resource private CreateCSPUStep createCSPUStep;
    @Resource private CreateCSPULogStep createCSPULogStep;
    @Resource private SendCSPUCreatedEventStep sendCSPUCreatedEventStep;

    public Long create(MyCspuSaveParam myCspuSaveParam){
        SaveCSPUContext context = initContextStep.initContext(myCspuSaveParam);
        checkRequiredParamStep.check(context);
        checkUnitStep.check(context);
        checkExpiringDateStep.check(context);
        checkBarCodeStep.check(context);
        checkBarCodeImgStep.check(context);
        checkBrandCategoryStep.check(context);
        checkProductDetailStep.check(context);
        checkSpecImgStep.check(context);
        createCSPUStep.create(context);
        createCSPULogStep.log(context);
        sendCSPUCreatedEventStep.sendEvent(context);
        return context.getCspu().getId();
    }
}

A more straightforward implementation reduces the number of components while keeping reuse, aligning with Ockham’s razor.

COLA 3.0 Changes

Remove Command

The initial design borrowed CQRS and introduced a Command pattern to separate command and query handling, which added indirection. The upgrade eliminates Command and replaces it with direct service methods.

public class MetricsServiceImpl implements MetricsServiceI {
    @Autowired private CommandBusI commandBus;

    @Override
    public Response addATAMetric(ATAMetricAddCmd cmd) {
        return commandBus.send(cmd);
    }
    // other methods omitted for brevity
}

Remove Interceptor

Interceptors were added to leverage the CommandBus, but Spring’s built‑in AOP already provides this capability, making the custom interceptor redundant.

Remove Convertor, Validator, Assembler

These naming conventions and components were intended to enforce team standards, yet they proved to be over‑engineered and were removed without affecting core functionality.

Class‑Scanning Optimization

COLA originally copied the TMF class‑scanning mechanism, which is unnecessary because Spring already offers bean discovery. The upgrade switches to ListableBeanFactory.getBeansWithAnnotation for retrieving @Extension beans.

Conclusion

The COLA 3.0 upgrade is essentially a “functional downgrade” that applies Ockham’s razor to strip away superfluous layers, leaving a lightweight framework that focuses on extension points and keeps the architecture simple, effective, and easier to maintain.