This is my second post on dev site. I hope you will enjoy my article about pure CQRS pattern. 😊
A year ago I heard about buzzword called "CQRS". I started my research and after some weeks I catch myself on using it everywhere. I thought it was good idea, but after some time I seen cons and my bad decisions.
So, the time has passed and now I'm ready to talk about it with some advices for newbies in CQRS.
At first, many peoples talks about not using it everywhere and I partially agree with them, but the point is that you can always use only CQRS without DDD, layers and others.
They are ofter goes in pair and I think this is the main purpose of problem.
As I mid, I have some experience with juniors. They often try to make something work, but not maintainable in long time.
For example, if you give junior task "create CRUD" then it probably would be a mess.
A god controller for everything with many private functions (Of course you should inform juniors why it's bad and teach them to do it in proper way!), but if you introduce CQRS and say "Hey, can you create use case with command and handler in the way I did before?" it will be more easier for junior and you.
It will not ruin the entire system and you can test it without magic, cuz logic will remain in handler.
Of course! These juniors deserve it. They are not some zombie coders, and it's good opportunity to teach them about good architecture.
I try to start with minimal environment. Just actions (single method from controller per file), commands, queries and handlers. I try not to make models in "domain" too smart if it's not required. They can remain anemic for now. And that's all.
You are not supposed to do more about it, but of course I recommend to use full of DDD/Hexanogal/buzzwords if you can see profits from it.
Thanks for read!
In my opinion good sources for CQRS, DDD and hexagonal architecture.