Understanding CQRS in ASP.NET core

preview_player
Показать описание
ASP.NET Core CQRS implementation example and theory. Trying to unlink MediatR from CQRS.

👉 Try Rider
RD5K9-4TXXW-KMV3G-NYWSF-3ZSTP

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

It is true when you think about it. In almost all languages the concept of CQRS has been kind of merged into Command Bus/Pipeline concept. So when you mention CQRS people are automatically like :Oh, you mean command gateway, command handlers, MediatR...

IvanRandomDude
Автор

It's nice to see how this channel is growing! Great content as usual, cheers!

Thepawlak
Автор

Nice! A short video that highlights the main point.

YuriiOkunets
Автор

You're on fire man hahaha nice video

JackRipper
Автор

In an Enterprise large scale solution, would you use a layer for the event sourcing such as Service Bus / Message Queuing? Given large scale loads if there's any system outages, those technologies can ensure data will actually reach the View Store. On our platform in my day job we had a "event_message" database table were we publish minimal information for an event to find the data to be synced rather than putting an entire record. Then a Service Bus publisher reads batches of records from there and is responsible for creating the Service Bus Topics on the queue. A Subsriber then reads those and farms topics off to Handlers which know how to query for relevent data. In your scenario here, that handler would query the main data store and then update the View Store, the big benefit being that these handlers run off process from the main Command layers and you can pool handlers to load balance on high traffic. It may seem like a lot of moving parts but I can imagine in huge scale systems that the time in process to update the View Store could potentially hold up the Commands and in reality what's the point fo "eventual consistency" if you're going to udpate the store immediately and hodld the command up anyway... With some kind of message queue as I outlined only a tiny bit of info needs to be in the "Event" and then the command can return immediately meaning more room to process incoming commands. If anything along the way dies then you have the Event published record so you could re-run the pushes. This could be either re-running the publish if that failed, or the Subscriber doesn't remove from the queue until the View Store update is finalised, so that could also be re-run the View Store update at ay time. One key part of all this is that each command would have a unique "correlationId" which appears on the message queue and then logs of each command are kept with that same value so you can still link all the actions together when debugging.

stephenyork
Автор

As always your explanation is awesome and helped me a lot to understand the topic. Thanks!!
But I have a few queries. Can you please answer them?

1) Is Materialized View as separate Read Database a good option than somewhat complex Event Sourcing?

2) At 2:40 your Process is projecting into View Store directly from Command rather than from Command Side Database Projection. Then what is the use of Command side Database in such case (In fact it is never used)?

3) At 8:52 when you need to query/load data at Command side, you read data from ViewStore(Read Db). Wouldn't it be better that in such cases, for e.g. business validations before saving, where we first need to query data at Command side, we use Commnand Db for query to avoid momentary stale data because of eventual consistency issue?

rajeshtikam
Автор

In a real case scenario where you are actually querying a real database vs an in memorydatabase I think you would have seen more differences. We prefere the cached scenario you talked about in the end, just clearing the cached version in a mediatR pipeline. So the "process" will only be fire on the next read, and not on every writes.

huguesviens
Автор

Great video regarding a very ambiguous topic :) One question that I have is how to do you handle de-sync in a non-eventsourced system? Asking for the case where we fail to build/update the query model (db down or any other transient issue). Furthermore, if business requirements change for the viewmodel, how would you reconstruct the data?

alexiosplomaritis
Автор

as usual i learn something from your videos, can you make a graphql asp.net core series? or is there any plan for that?

fifty
Автор

I don't understand how it can be useful for one to many or many to many relationship. I can see the benefit if you have 4 foreign keys with a one to one relationship. In a database you can just create a big table so you don't have to do joins, but with a one to many relationship you have to do them otherwise you could have a billion rows.

TeAmpsXt
Автор

Love to hear that there is somebody else that is not a MediatR fanatic. So I have had endless arguments over what is CQRS. I think the separation of DBs is clearly CQRS, but what's your opinion on:
1. having different C# models going to the same db. eg a POST which has the full model, a PATCH that has a partial model, then different reads that have different projections of the data. So different C# models which interact with the same set of data.
2. What if the read method and write method are in the same class but have different models and different databases.
Would you consider those CQRS, putting other design aside?

brandonpearman
Автор

Just a suggestion, don’t use dark red on a dark grey background, it’s very hard to make out what you are drawing.

henningtorsteinsen
Автор

Nice, that you focus on the actual pattern and skip mediator....

ketenenekete
Автор

Please normalize your audio. Your content is too good not to :P.

PaulSebastianM
Автор

Hi Raw Coding, I am from Ukraine and I always watch your videos, currently, I see war behind the window, please assist us, let the entire world know about the situation in Ukraine. Everyday Russian kill us. But we are brave and stay here, for one purpose - defend our families and country.
Glory to Ukraine. Thanks for your attention

ivansydorchuk