I'm an engineering manager at a rather large e-commerce company in Germany, and I've never worked with, or implemented any systems using CQRS, though I'm sure our organization has quite a few services using it. I agree with the statements in this article to a large extent, however I think it is ignoring a lot of the problems CQRS is meant to solve, which is primarily not something CRUD can do for you out of the box.
To be a little more specific, CQRS usually comes up with event sourcing, where you not only want to know the current state, but also to be able to track down changes. Now I'm not saying that CQRS is the only way doing it, but ignoring it completely leaves your post a bit unfinished in my opinion.
You should probably also extend the post on how the benefits of CQRS itself, namely the separation of reads and writes, and hence making scalability easier, can be compensated for by CRUD combined with other techniques.
You are right. My target isn’t to remove CQRS from apps that needs it, my target is to remove it from apps that doesn’t need it. If you’re for instance building a real time trading platform with hundreds of writes per second, you obviously have to use CQRS. However, using it when it’s not needed is madness, and I’ve seen it used a LOT when it wasn’t needed.
That might be, but it would probably be difficult to ensure it was complete. Great developers knows when to apply it intuitively, which of course is (almost) never 😊
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm an engineering manager at a rather large e-commerce company in Germany, and I've never worked with, or implemented any systems using CQRS, though I'm sure our organization has quite a few services using it. I agree with the statements in this article to a large extent, however I think it is ignoring a lot of the problems CQRS is meant to solve, which is primarily not something CRUD can do for you out of the box.
To be a little more specific, CQRS usually comes up with event sourcing, where you not only want to know the current state, but also to be able to track down changes. Now I'm not saying that CQRS is the only way doing it, but ignoring it completely leaves your post a bit unfinished in my opinion.
You should probably also extend the post on how the benefits of CQRS itself, namely the separation of reads and writes, and hence making scalability easier, can be compensated for by CRUD combined with other techniques.
Notice how I liked your comment? 😉
You are right. My target isn’t to remove CQRS from apps that needs it, my target is to remove it from apps that doesn’t need it. If you’re for instance building a real time trading platform with hundreds of writes per second, you obviously have to use CQRS. However, using it when it’s not needed is madness, and I’ve seen it used a LOT when it wasn’t needed.
I guess that's fair, though you could have gone slightly further by adding a checklist about when it's actually a good idea to go with CQRS. ;)
That might be, but it would probably be difficult to ensure it was complete. Great developers knows when to apply it intuitively, which of course is (almost) never 😊