CQRS Myths | 3 Most Common Misconceptions

preview_player
Показать описание
Here are the 3 most common myths I constantly see about CQRS when it's explained in blog posts or videos. This video explains exactly what CQRS is, as well as what it is not.

💥 Join this channel to get access to source code & demos!

🔥 Don't have the JOIN button? Support me on Patreon!

Greg Young Archived Posts:

0:00 Intro
0:50 CQRS Definition by Greg Young
3:06 Myth #1: Multiple Databases
3:55 Myth #2: Event Sourcing
4:40 Myth #3: Async Messaging
5:20 CQRS is NOT
6:10 Feedback/Comments

#cqrs #softwarearchitecture #softwardesign
Рекомендации по теме
Комментарии
Автор

Have you been confused by CQRS? What has made it confusing to you?

CodeOpinion
Автор

I've mostly stayed away from CQRS and stuck with the DDD design. Recently I started breaking up all the DDD within one of my projects in favor of CQRS. Though I have to think a little different I really like the way it is coming out and it does open up opportunities where I started having trouble with one service needing another service causing me to get stuck in the circular pattern. I'm using Mediatr with C# and it is very nice. Thanks for the videos.

kolesplace
Автор

Great explanation of CQRS. Keep up the good work!

muddpiemojo
Автор

I would most definitely like to see more content on why one would apply CQRS, without adding all these other bits (async messaging, etc). Many of us work on monolith application with large WCF services for example that have 100 methods on each service.

loxlover
Автор

I just want to thank you for clarifying this. Nowadays, I feel less inclined to use the Service pattern, since it makes you code more convoluted.

Sure, you could take SOLID to its extremes, and create services according to CQRS. "FileWriteServices" and "FileReaderService" etc. It really amazed me to see that level of engineering in a WPF application.

In a server-side application, I'd much rather focus on the Command, Query, and Event pattern, and it is not itself CQRS, but an application of it. The principles are there. Then I would create simpler services underneath that layer.

The structure of your code, classes and methods, should signify its purpose as seen from the behavior. Having them being organized and named according to behavior or event (past tense) does make it easier to navigate, reason about, and make changes.

And that is what we, as developers, should strive for - since it makes us more productive.

marna_li
Автор

I am currently studying the concepts of modern software architecture for my next project, and most of the tutorials/books will make an impression that CQRS and ES are one thing. This was raising suspicion in me all the time, and thanks to this video, I now see my suspicions were correct.

zenmony-dot-com
Автор

I have recently came across 3 youtube channels that are pure gold, one of each is yours. I love how concise and to the point but yet you make it so easy to understand. I wished my co-workers would watch your videos :(

DanielRodriguez-dsqs
Автор

Really good video more videos to CQRS, Event Sourcing or DDD are always welcome (especially because I like your way of simplyfiing and explaining things). Keep up the great work :-)

kgnet
Автор

Another important topic Derek! There is a lot of confusion wrt CQRS, as well as EventSourcing that often need to be overcome. Your short videos are really valuable sources for instructing developers who have 'grown up' with other design patterns.

You've done some great work on event sourcing already, but I'd love to see what you would do with the event sourcing concept where there is as much, if not more confusion. Issues like eventual consistency, busses and multiple data-stores are design choices rather than requirements.

Keep it up!

leopoldodonnell
Автор

Just found your channel, absolutely spot on content for where I am right now. Thank you!

deanoldfield
Автор

thank you so much for this video! You have not idea how useful it was.

Keiktu
Автор

That diagram confused CQRS with an entire microservice.

TomBauto
Автор

Good to see a concise clarification on the topic. But when and where did it start to "go" wrong, from Greg's idea to that mix-in of other concepts and technologies?

krccmsitp
Автор

Thanks a lot for the simple explanation!

shaddydxd
Автор

Love this video. Is it ironic that your brand is Code "Opinion" but this definition is a "fact" considering it relays the exact message as what Greg Young has (the creator of CQRS) states about CQRS?

ndev
Автор

Apart from CQRS what is your take on the idea that the functions that we write should either return data or change state but never both? As a junior dev I've heard this somewhere and was wondering if that's a principle to live by as a programmer.

iliyan-kulishev
Автор

It would be great to add a "why" to these explainations (CQRS or event driven architecture or event sourcing)

MerrionGT
Автор

What if you want to return some result from your commands? How do you deal with that? Some practical examples would be appreciated

muhammadazeez
Автор

Ok so, but how about readModel/writeModel in CQRS? Need we realise it?

белка-уб
Автор

Hi, thanks for this great video. I've one query like if I'm using microservice architecture is it important to create different microservices for command and query?

rishavgarg
visit shbcf.ru