What is important (for most systems)
• Support a lot of concurrent reads
• Fast as possible
• Combine, aggregate, calculate
• Create new views / reports without risk of
introducing bugs in existing code
• Scale reading independently of writing
• Fewer writes than reads
• Performance not that important
(< 1s probably ok)
• Simple models that are easy to understand
and reason about
• Easy to test
• Simpler and smaller write-models, that are easy to reason about,
because they don’t need any view-logic. (getters etc.)
• High-performing reads, since you fully utilize your underlying
database server, and don’t need ORM’s for reading.
• Extreme ﬂexibility since the only things needed to build new
view-models are SQL
Beneﬁts of using CQRS this way
• You couple the modules through their underlying persistence structure!
• The handwritten SQL is expecting certain columns names etc. So changing
the write models will potentially break read models.
• So, have strict rules for where you are allowed to use this
Only CQRS between modules
• If you have views that combines information for a lot of different
• If you have complex data structures that can beneﬁt from doing
data manipulation directly in the database (joins, subselect,
When to use
• Even though the app communicates with a lot of underlying
subsystems, it only fetches data for a single child, and
performance therefore is not a problem.
CQRS not needed for the app
Henrik Møller Rasmussen!
IRC: Come join us at #ddd
The digital daycare