Up next in 10
How to Use CQRS Pattern in .NET: A Dash of .NET - Ep. 3
7K views
Jan 29, 2024
Dive into the world of CQRS (Command Query Responsibility Segregation) with our latest video! In this session, we'll unravel the mysteries of CQRS and compare it with the traditional service layer model. Learn how CQRS can enhance the scalability, maintainability, and performance of your applications. Agenda 1. What is CQRS. What different between CQRS and service layer model. 2. A real life example that uses CQRS (user profile management system). 2.1 Application description with 2.2 Description of API methods 2.3 Description and realization model level 2.4 Description and realization controllers 2.5 Description and realization app level šŗ CSharp TV - Dev Streaming Destination http://csharp.tv š C# Corner - Community of Software and Data Developers https://www.c-sharpcorner.com #csharptv #csharpcorner #dotnet #adashofdotnet #csharp #CQRS
View Video Transcript
0:00
Hi everyone and welcome back to C Sharp TV. Once again you are watching a dash of .NET quick
0:04
bites of .NET wisdom and in this episode we're going to learn about CQRS. Now am I an expert
0:11
No way at all. To talk about CQRS today we'll be joined by Victoria
0:15
the senior software engineer and an expert not just in .NET or C Sharp but a lot of tech side
0:23
Hello hello. Thanks Victoria for joining us today and we're really excited to learn about
0:29
the software architecture stuff today and how CQRS can supercharge our application
0:36
I'm not going to take any more of your time and I'll let you take the stage
0:40
Okay yeah let's go. Okay today we will talk about CQRS, it's command and query responsibility
0:50
desegregation. It's what's on of pattern, architecture patterns. So what I will talk
0:59
my plans I want to talk with you about history of architecture. Then we will talk about a little
1:08
example of a service, very small service and we will implement it from step by step from
1:19
first architecture style to modern architecture styles and of course we will talk about CQRS
1:27
Okay let's talk. First what we had it's spaghetti code architecture. It's when
1:36
any developer wrote code like he want. Yes and so it's not a useful code if something
1:49
if you talk something in one class it can be broke in another class. It's useful for
1:57
this architecture yeah and of course it's not a good architecture style. Okay then
2:06
developers think why we should we should leave with this architecture, we should
2:14
get some new yeah. So they think and create layers architecture when I think all developers know
2:25
this architecture style. It's when you have UI, API, ABI, wherever some UI. Okay and so in the
2:33
middle business logic and that access layer when you use your database or something like that
2:43
something which have data. Okay but problem of this style it's in UI it's spaghetti code
2:53
in business logic it's spaghetti code too. Yeah it's more useful because it's you have layers
3:03
but what happened inside it's spaghetti code. So but it's better of course
3:12
So developers creating solid principles yes and they started to think why business logic it so
3:22
depends on that access layer. Yes so they true turn this implementation and of course change
3:34
your squares to cycles and create clean architecture. Yeah it's very close yeah
3:43
So what is clean architecture? It's when you have the main layer in your center of
3:51
architecture and UI tests infrastructure and other world talk with the main layer
4:00
true services. Yeah. Okay CQRS. CQRS it's do you remember when we in .NET started to use setters
4:14
and getters in our classes? When we started use one function to set our field and get another
4:25
function. Yes it's same idea but in your microservices, in your system when you use
4:33
one application to write and other application to read. Why we need it? If you imagine for example
4:44
internet shop around 80 maybe 90 percent of all queries it's just read data and only 10 maybe
4:54
less percent it's change your data. So it means that you should can improve your path of your
5:05
system to read data and other parts it's separated. Yes this process you should can for example here
5:16
10 pods and here only one pod you don't need to write data a lot of pods in your Kubernetes
5:25
Yeah if we will talk about this about Kubernetes. So it doesn't mean that you should use two
5:33
databases. No of course not it can be one databases. Some project write data and use
5:41
entity framework but for read they use dapper because dapper read data more faster easier
5:50
yeah better but entity framework very powerful to write and change your data. So maybe
5:59
this guy it's not database maybe it's just materialized view or maybe elastic search
6:08
everything but main idea that you should separate your application to two apps yeah. Okay go to
6:19
our example it's user service it's very simple user service with only one feature it's a register
6:29
user what we should do we should check that we don't have user with this email we should create
6:36
user in our database we should add bonuses to this user because he's good guy and register in
6:44
register in our service and send email that everything okay. Yeah so first implementation
6:54
it's our spaghetti code it's a controller and it's just path of my code because here I don't
7:05
have profiling I don't have normal logging authorization error processing all of this stuff
7:12
because if I will show you it it will vary a lot of code in one function of course it's
7:21
not useful yeah. So okay clean architecture yes next level it's when we have a user service
7:33
which will save our user create our user and some notify service which will send email
7:43
maybe not email doesn't matter. Okay yeah this our function better yeah of course better you have
7:54
you can reuse send email you can reuse create user with bonus it's not so good you know practice
8:03
here create user with bonus it should be user service and bonus service we should create user
8:11
and send bonuses I will show you why it's first problem of our layers yeah I will show you. Okay
8:24
go to create users do you have do you see any difference between create users and first
8:32
implementation I don't see use it I don't see it too it's mean that we just change location of our
8:42
code to just other file and yeah it's not so good we don't have solution here for example question
8:53
where we should validate email yeah maybe in controller maybe we should create new
9:01
function and user service that validate email maybe we should create maybe we should create
9:08
it in user service and call it here maybe in controller where is yeah we don't know I don't
9:17
know any I saw any developers who use who create this method and service but call it in controller
9:27
some people call it in create user method because how we can create user and don't
9:36
without validating email okay a second question where is should be safe changes it should be here
9:45
but but what if balance it's real other table yes and we will have balanced service
9:53
with method at balance yes so it's mean safe change it should be in controller because
10:00
maybe we want that these two operation will be in one postgres transaction
10:09
don't know okay so some people get put safe changes here in user service some people
10:20
put it in controller some people put it you know use a union or pattern and it's other methods
10:33
so a lot of questions and spaghetti code too yeah so here around five years ago I think
10:41
maybe layers it's not so best solution for create your application maybe we should create it it's
10:50
not based on layers but based on user features yes user use cases uh we don't think about
11:01
oh what layer is it maybe it should be in repository maybe it should be in user service
11:09
maybe it should be in controller why I should think about it I want to think about use cases
11:16
not about layers so uh and then uh around five years ago I read about uh mediator I read about
11:28
handlers and I love it so much because uh I can start think about features not about services not
11:41
about repository not about all of the stuff but only about handlers of my uh request so you can
11:50
you can put in your handler everywhere yeah you can put a domain model you can put a docker legacy
11:59
code api client to other service doesn't matter matter it's that uh your handler it's one feature
12:08
yeah it's one use case of your application okay what happened with user services in this new
12:18
model uh okay let's imagine simple user services it have these functions I uh brush use uh get user
12:30
method in yellow because it's query it's uh doesn't change our data data of user so it's very close to
12:42
secure as model model yeah uh so yellow command it's just part of our application okay uh so what
12:54
happened with our registry user command uh handler it's very simple you just you should create user
13:06
you should give bonuses of this user and you should notify it what different yeah I can of
13:16
course I can create bonus services and create function gif and in uh controller uh put these
13:26
three lines two yes user service send user service or user service create user bonus service
13:34
give bonuses and notify service send or email but here I can reuse this uh register user yes feature
13:48
I can use it in other places and I started to think about registry user not like about API
13:57
comment I think about like about feature so I want that everywhere think about handlers mediator
14:08
and started to beat application not like layer application but like a feature application yeah