Older but still relevant article dealing with question of technical patterns and how they are filled with myths and mishaps. Quite often, this happens to CQS and CQRS. By Oskar Dudycz.
Command and Query Responsibility Segregation uses the same definition of Commands and Queries that Meyer used and maintains the viewpoint that they should be pure. The fundamental difference is that in CQRS objects are split into two objects, one containing the Commands one containing the Queries.
Greg Young
Some myths on CQRS topic that author will try to explain:
- You need two databases
- You have to use a messaging queue (e.g. RabbitMQ or Kafka)
- It’s hard to apply and complicates the architecture
- You’ll be facing Eventual Consistency
- You need to do Event Sourcing
Nothing prevents the Write Model and the Read Model from having the same structure or using the same tables. Nothing then stops you from using a relational database, even the same table for reading and writing. If you prefer, you can continue to use ORM. CQRS allows you to have different storages for different business cases. You can, for example, have a relational database on the write model and document database on the read model (e.g. Elastic Search for full-text search) or any other combination. The article also provides a great selections of links to further reading on the topic. Nice one!
[Read More]