How to use cqrs to effectively cut the code base according to business functions?

The structure of items and discussion spaces are as sensitive as tab or indent size . When we enter someone's apartment , Even if it is decorated according to IKEA's default settings , It always looks a little different . It's absolutely reasonable . Different apartment sizes and room layouts will vary .

It's similar to our software project . Each has slightly different assumptions and characteristics , But some common features can be distinguished , Am I right? ？

Like everyone else , I started with a strict technical split , There I have one for service 、 contract 、 mapper 、 Folder of data model, etc . at that time , I think I had everything original and appropriate at that time . However , This assumption has changed .

Some time ago , I am here .NET In the example, I changed my event source . Now? , They are completely divided according to business functions , Not technical features . Why did I do this ？

My path to making this decision is gradual . When I create a repository , I'm at the stage of dividing the system into modules . Each module is a separate project . The first Department of the project is aggregation , So it's a business sub module . However , In the folder , The division is still technical . command 、 event 、 Value objects are distributed in different subfolders .

This is an acceptable solution , But I still feel uneasy . The breakthrough took place in ……

... I am here Angular Work longer on . stay “ new Angular” in , Decomposing the code base into components is essential . In the same folder , We kept HTML Views and components TypeScript Code . what's more , We also put unit tests together ！ At first , I think it's strange , But then I realized that it helped to improve efficiency .

Usually , When we deal with a given business function , We use the same template ：

• API Endpoint ,
• Request type ,
• Some classes to handle it ,
• Data model .

Traditionally , We spread it to different places . We have to be in multiple folders 、 Jump between files, etc . Of course ,IDE Shortcuts can help us do this , But we have to constantly jump from one place to another, and that hasn't changed . We always switch contexts . When we are interrupted by phone calls or social media announcements , I don't need to tell you , You'll know for yourself how inefficient it is to work in this situation .

The jump between files can be compared with this ： When we put everything nearby , Preferably in a file , We can be more efficient . We may not even need three monitors or a monitor as wide as a football player's shoulder .

Keep this split right CQRS Very effective . It isolates our operations and splits the application code vertically rather than horizontally . Event traceability introduces more important improvements , Because we don't need a unified data model （ for example EntityFramework Medium DBContext）. Each operation is based on events that we can save in the command folder .

It looks something like this ：

stay Carts The business function file has the following subdirectories ：

• Files with commands and handlers , for example Carts/AddingProduct/AddProduct.cs
• File with event command is being created , for example Carts/AddingProduct/ProductAdded.cs
• Use the handler to query , for example Carts/GettingCartById/GetCartById.cs
• Use projection to read the model , for example Carts/GettingCartById/CartDetails.cs

Of course , No, CQRS or Event Sourcing Projects can also benefit . Rule of thumb ： Put things that change together . In addition to reducing context switching , This splitting can also improve the understanding of what is happening in the business , Manage dependencies and even eventually extend . It is easier to extract features into special objects Microservices in .