CQRS vs CQS

The claim under test

A service is organised like this. Controllers, services and interfaces are all cleanly split by intent. Almost every engineer who sees it calls it CQRS, and it is easy to see why: the word "command" and the word "query" are right there in the path.

controller/
├── command/        AreaCommandController
├── query/          AreaQueryController
└── interfaces/     IAreaCommandService, IAreaQueryService
service/
├── command/        AreaCommandServiceImpl
├── query/          AreaQueryServiceImpl
└── Interfaces/
repository/
└── AreaRepository          ← one repository
model/
└── AreaOfInterest          ← one entity, one table

It is a genuinely good structure, but it is not CQRS. To see why, you must examine the two definitions the industry routinely conflates. They are not two names for the same idea; they operate at entirely different levels of the system.

CQS: a rule about methods

Command Query Separation is a principle about individual methods. Fowler credits Bertrand Meyer with coining the term, in Object Oriented Software Construction; the crisp two-part formulation below is Fowler's own articulation of it, which is worth knowing before you attribute the wording to Meyer in a design review. It predates microservices entirely and applies just as well to a linked list as to a distributed system.

The practical payoff is that you can call a query anywhere, such as in a log line, in a debugger watch expression, or twice in a row, and be confident nothing moved. The moment a method both mutates and returns, that confidence is gone.

// Violates CQS: mutates AND returns. You cannot call this twice safely.
public Area changeCoordsAndReturn(String id) { … }

// Obeys CQS: a command returns nothing…
public void changeCoords(String id) { … }

// …and a query is free of side effects.
public Area findById(String id) { … }

CQRS: a decision about models

CQRS operates one level up. It is not about method signatures; it is about having two different models of your data, one shaped for writing, one shaped for reading.

Two clarifications from the same page resolve the most common objections, and they address opposing concerns. This nuance is exactly why the pattern requires careful reading rather than pattern-matching on dir names.

Fowler does allow a lightweight variant, and this is the sentence most often used to defend a package split. Read it closely, because it says something narrower than it first appears:

"Rather like views in relational databases" is the load-bearing phrase. A database view reshapes data: it denormalises, joins, hides columns, presents a different projection of the same rows. An interface that returns the identical entity the command side writes is not a view of the model; it is the model with its methods sorted into two lists.

The three tests

Rather than argue definitions, apply three mechanical checks. Passing any one of them is a reasonable claim to CQRS. Failing all three means you have command–query separation, which is a good thing to have and a different thing to call it.

Run them in order and stop at the first "no". The tests are cumulative, because each one presupposes the last. A projection is meaningless without a read model to project into, and a read model is meaningless if the query side still reaches the write repository.

What this looked like in production

Doing it properly

Below is the transition. The first tab is the shared-model version; the second introduces a read model and a projection. Note that the read model is not a DTO: a DTO is a transport shape mapped on the way out, whereas a read model is stored in its read-optimised form so the query does no joins at all.

@Service
@RequiredArgsConstructor
public class AreaQueryServiceImpl implements IAreaQueryService {

    // The same repository the command side writes through.
    private final AreaRepository areaRepository;

    @Override
    public List<AreaOfInterest> findByLayer(String layerId) {
        // Returns the write entity. Every caller now depends on the
        // persistence shape, and every read pays for lazy-loading.
        return areaRepository.findAllByLayerId(layerId);
    }
}

/**
 * Read side. Depends on nothing the write side owns: its own repository,
 * its own model, no JPA entity in any signature.
 */
@Service
@RequiredArgsConstructor
public class AreaQueryService {

    private final AreaReadModelRepository readModel;

    /**
     * One row already contains the layer name and the entity count.
     * No joins, no lazy-loading, no N+1.
     */
    public List<AreaSummary> findByLayer(String layerId) {
        return readModel.findByLayerId(layerId);
    }
}

/** The read model: flat, denormalised, shaped for the screen that shows it. */
public record AreaSummary(
        String areaId,
        String name,
        String layerId,
        String layerName,      // denormalised, no join at read time
        int    entityCount,    // pre-aggregated
        Instant lastModified
) {}

/**
 * Keeps the read model current. This is test 3: without a projection there
 * is no read model to speak of, only a second name for the same table.
 */
@Component
@RequiredArgsConstructor
public class AreaProjection {

    private final AreaReadModelRepository readModel;
    private final LayerLookup layers;

    /**
     * Applies a write-side event to the read model.
     *
     * REQUIRES_NEW is load-bearing, not decoration. An AFTER_COMMIT listener
     * runs inside the transaction synchronisation of the transaction that
     * just committed, so a REQUIRED-propagation write from here joins a
     * transaction that can never commit again: the upsert is silently
     * discarded, or throws, depending on how the repository is declared.
     * A brand-new transaction is the only way this write reaches the database.
     */
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void on(AreaChanged event) {
        var layerName = layers.nameOf(event.layerId());
        readModel.upsert(new AreaSummary(
                event.areaId(),
                event.name(),
                event.layerId(),
                layerName,
                event.entityCount(),
                event.occurredAt()
        ));
    }
}

Re-run the three tests

The tests are not a one-off rhetorical device, they are the acceptance criteria. Run them against the code above and each one now answers differently, and for a specific structural reason rather than because the packages were renamed:

Three yeses is CQRS. Two is a half-migration, and it is worth naming which two, because the combinations fail differently: a separate model without a projection is a read model that goes stale; a separate repository over the same entity buys you nothing but an extra type.

When not to reach for it

This is the part most CQRS tutorials omit, and it is the part Fowler is most emphatic about. The pattern has a real cost and a narrow window of benefit.

• Reads and writes have genuinely different shapes, so the screen needs a join-heavy projection the write model makes awkward.
• Read and write load differ by orders of magnitude, and you want to scale them independently.
• The domain is complex enough that two sets of rules pull one model in two directions.
• Your system is essentially CRUD, so the split is cost with no return.
• You want "clean architecture", but organisational tidiness is a reason for CQS, not for CQRS.

Canonical sources

• Martin Fowler: CQRS · the definition, the shared-database clarification, and the caution.
• Martin Fowler: Command Query Separation · Meyer's method-level rule, with its exceptions.
• Martin Fowler: Reporting Database · the lighter-weight alternative to reach for first.
• Chris Richardson: CQRS pattern · the microservice framing, with trade-offs listed.