I find CQRS pretty interesting. I wrote an article last year about some of our practices.
For me, CQRS answered a problem that I kept running into when I would create applications. Using 3 layer program structure, I always ended up with a bloated data model that shared concerns of both the presentation and business layers. It became harder to maintain over time as it became less clear which bits of data were important (read as: changes were breaking) to which layer. Because they were all housed in the same set of normalized tables. Even applying CQRS at a minimal level (for example, separate tables for business logic vs presentation, writing to both on save) helps to improve the situation.
The problem with learning about this practice is that it has been conglomerated with a lot of other things over time. So when you try to learn about it, you end up "drinking from the firehose" of myriad other dimensions around it (like DDD, event sourcing, eventual consistency, optimistic concurrency, etc). I also utilize most of these since they are progressive optimizations, but the pattern is usable without them. And the shift in thinking was too big for me to do all at once.
I find CQRS pretty interesting. I wrote an article last year about some of our practices.
For me, CQRS answered a problem that I kept running into when I would create applications. Using 3 layer program structure, I always ended up with a bloated data model that shared concerns of both the presentation and business layers. It became harder to maintain over time as it became less clear which bits of data were important (read as: changes were breaking) to which layer. Because they were all housed in the same set of normalized tables. Even applying CQRS at a minimal level (for example, separate tables for business logic vs presentation, writing to both on save) helps to improve the situation.
The problem with learning about this practice is that it has been conglomerated with a lot of other things over time. So when you try to learn about it, you end up "drinking from the firehose" of myriad other dimensions around it (like DDD, event sourcing, eventual consistency, optimistic concurrency, etc). I also utilize most of these since they are progressive optimizations, but the pattern is usable without them. And the shift in thinking was too big for me to do all at once.
Great article! Thanks for sharing :)