DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Scaling Site Reliability Engineering (SRE) Teams the Right Way
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • What Is mTLS? How To Implement It With Istio

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Scaling Site Reliability Engineering (SRE) Teams the Right Way
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • What Is mTLS? How To Implement It With Istio
  1. DZone
  2. Data Engineering
  3. Databases
  4. Answer to the Article ''CQRS Is an Anti-Pattern for DDD''

Answer to the Article ''CQRS Is an Anti-Pattern for DDD''

This article is an answer to the benefits and drawbacks of CQRS under the light of the DDD practices.

Sylvain Leroy user avatar by
Sylvain Leroy
CORE ·
Sep. 25, 20 · Opinion
Like (7)
Save
Tweet
Share
4.98K Views

Join the DZone community and get the full member experience.

Join For Free



This article is an answer to the benefits and drawbacks of CQRS under the light of the DDD practices.

The original article written by Hristiyan Pehlivanov can be found here.

Despite the provoking title, the article is well-balanced and you may find valuable insights there.

TL;DR: CQRS is a not a silver bullet.

CQRS Is Not a Silver Bullet

Well, it's obvious, and despite what some software programming theorists may say, there is no perfect design pattern or architecture model that is a fit for all.

DDD, Onion Architecture, Clean architecture: these concepts rely on some good sense and one or two successful implementations in a given context.

CQRS has the same issue. Plus, there are some misconceptions about it that confuse practitioners.

CQRS Maturity Level

As I understand CQRS and practice it, I usually distinguish four levels of maturity

  1. CQS: Command and Query Segregation
  2. Read and Write model
  3. Read and Write Datastores
  4. Event sourcing

Level 1: CQS: Command and Query Segregation

This part is easy to understand. In your code, you should distinguish read and write operations and avoid mixed ones as much as possible. Your write operations should follow the Command design pattern.

I also recommend implementing a Command Bus interface that will work for the next maturity levels.

In Java, you may add the following tricks:

  • Read operations are read-only transactions
  • If you aren't following DDD, read operations are performed directly in your controller. You don't create services. You convert directly your queries into a JSON view.
  • Write operations may use aggregates like offered by an ORM

Level 2: Read and Write Model

The second level of maturity requires to have two different models (and possibly repositories): the read model and the write model.

The architecture keeps a single data storage.

The read model is optimized to returns directly the data required by the API. For example, you are using Spring JDBC or MyBatis for the read model and Hibernate for the write model.

The write model is created by following the actions required by the business. Each command is a business use-case or operation.

The BDD or TDD approach will help you to build the necessary commands.

The execution of the commands may trigger events. The event bus and the event loop are stored into the memory of the server. Nothing complicated there.

Level 3: Read and Write Datastores

The third level of maturity takes the principles implemented in the previous stages and add another constraint: we have two separate data storages.

The implementation complexity increases and there is a major concept to be implemented:

  • model synchronization: synchronously or asynchronously, the events produced by the commands must trigger a refresh of the read database

Moreover, your event system has to be externalized for example as a message bus (Kafka, Rabbitmq). It will help you to safely keep your messages being processed.

Level 4: Optional Event-Sourcing

Well, it is not a maturity level but another practice that fits with CQRS. Your commands are using the writing model to modify the write storage. Instead, your commands produce application events. These events stored into a log and can be used to replay the history of a database and eventually restore it.

More details can be found here.

The usage of Event Sourcing is totally optional to CQRS.

Conclusion

In my opinion, the benefits of CQRS are:

  • Testability: Command are objects and not parameters. This way the command handlers are easy to test and to mock. The object validation is also possible on the commands using Hibernate validation.
  • Functionality/Maintainability: a CQS architecture is easy to read since everything is business-oriented. No mega service or Godclass DDD repositories.
  • Productivity: CQS offers a big benefit that we remove almost all DTO/Value object code and respect DRY principle. No need to have two abstractions layers between your DAO, your value object, and the JSON view you are returning. You should use a DAL optimized for read access and JSON conversion
  • Fun: Almost everything has to be built from scratch. Ok it exists some (paid) frameworks but I wouldn't use them.

The drawbacks of CQRS are:

  • More code: yes instead of a basic function you have to write a command object, a command handler ( your tests), validation etc. But the code is easy to read and self-explanatory
  • Asynchronism issues: since your write data storage and read data storage are separated, the data synchronization may be delayed and causing UI issues for your users.
  • More layers: command, command bus, event, event handlers are new concepts. Building a service or a DDD repository looks easier ( at the beginning)
  • Technology abstraction: DDD modeling and CQRS are not quite compatible, more thought has to be provided on it and a compromise to be found.
Database Command (computing) Anti-pattern Event

Published at DZone with permission of Sylvain Leroy. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Scaling Site Reliability Engineering (SRE) Teams the Right Way
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • What Is mTLS? How To Implement It With Istio

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: