Why CQRS Is Becoming a Practical Architecture for Complex Business Applications

The article, originally from InfoQ China, cites Gabriel Schenker who argues that many modern applications suffer from unnecessary complexity and inefficiency because they do not adopt Command‑Query Responsibility Segregation (CQRS), and that CQRS will become one of the most practical architectural patterns for line‑of‑business (LOB) applications.

Schenker identifies two main sources of this complexity: the widespread use of anemic domain models, where entities contain only data and the business logic resides in separate services, and the use of a single interface for both reading and writing data, which eliminates true read‑write separation.

Data reads are typically far more frequent than writes.

Read operations often retrieve large data sets or lists, whereas a write usually affects a single aggregate.

From a user perspective, read performance should be higher than write performance; users are more tolerant of occasional write latency.

To illustrate the basic principles of CQRS, Schenker created a concise, real‑world‑driven example of an online shopping site that includes a product catalog and a shopping‑cart feature.

Vladimir Khorikov defines three types of CQRS and contrasts them with a No‑CQRS approach:

In a No‑CQRS architecture, the same domain model handles both commands and queries. This does not increase code complexity, but it makes read‑side optimization extremely difficult or impossible.

In a separated‑class structure, domain classes handle commands while Data Transfer Objects (DTOs) return read data. This introduces some duplication, but Khorikov believes it strikes a good balance between complexity and performance for most enterprise applications.

In a fully separated model, different APIs and models implement reads and writes. This enables query optimization, caching, and is well‑suited for high‑read‑load scenarios.

Using separate storage for queries—such as a relational database for writes and a NoSQL store for reads—allows the system to achieve eventual consistency, offering the highest scalability at the cost of increased complexity.

Khorikov emphasizes that CQRS is not a binary choice; the degree of separation should be determined by the application’s requirements, aiming for a balance between separation and the resulting complexity, and it should only be introduced when read‑side scalability is a critical concern.

See the English original: Advantages of CQRS