Command-Query Separation and Command-Query Responsibility Segregation. Two design principles explained.
Command/Query Responsibility Segregation is about dividing a system into two subsystems – a query system that can only read data and a separate command system that can only write.
Commands and Queries themselves are usually messages or DTOs passed in to these subsystems.
CQRS is really simple. Sometimes the idea gets conflated with other concepts such as Event Sourcing and DDD, but that is not CQRS. So, what is it then?
A remote version of my Onion Architecture talk from DDD East Midlands with a few extra slides and alterations. Presented at a local evening meetup and streamed to YouTube.
Those that have worked with me will know I’m a big advocate for Aspect-Oriented Programming. I generally like to “bolt on” concerns that sit outside of the main logic using the decorator pattern or some kind of behaviour that can wrap around a class or method, which follows the Open/Closed principle.
A lot of software engineering is about drawing boxes. That is, deciding how to break down the code we write. We don’t just write everything in the
Main method. We set boundaries, create abstractions, and divide things into single responsibilities.
Explaining how I reason about the building blocks of Onion Architecture, Domain-Driven Design and Command Query Responsibility Segregation in an event-driven microservices architecture. How it all fits together in my head, the concepts they share, and the mistakes I’ve made along the way.