Mastering ASP.NET Core with Minimal APIs & CQRS -Part 05: CQRS & Mediator — Class Structure

CQRS Architectural Pattern

Command Query Responsibility Segregation (CQRS) is an architectural pattern that separates reads and writes into 02 distinct components. This architectural pattern benefits complex systems that require scalability, performance optimizations, and maintainability.

CQRS divides an application’s operations into two categories:

1. Commands — Modify data but do not return it.
2. Queries — Retrieve data without modifying it.

By separating these concerns, we can optimize each operation independently and ensure better performance and maintainability.

Benefits of CQRS

1. Scalability: Since the read and write models are separate, they can be independently scaled based on the system’s demands.
2. Optimized Queries: The read model can be specifically designed to support high-performance queries without being constrained by the write model’s complexities.
3. Improved Maintainability: By decoupling commands from queries, the system is easier to manage, refactor, and evolve over time.
4. Better Security and Authorization: Commands and queries can be secured independently, restricting unauthorized access to sensitive operations.
5. Event Sourcing Integration: CQRS works well with Event Sourcing, enabling an event-driven architecture that maintains a complete audit log of all changes.

Mediator Pattern

The Mediator Pattern is a behavioral design pattern that promotes loose coupling between objects by centralizing their communication. Instead of objects communicating directly with each other, they interact through a mediator, which controls and coordinates their interactions. This improves code maintainability and reduces dependencies between components.

Key Concepts

1. Mediator: The central component that defines communication between objects.
2. Colleague: Objects that participate in communication through the mediator.
3. Concrete Mediator: Implements the mediator interface and coordinates the interaction.
4. Concrete Colleague: Implements the colleague interface and interacts through the mediator.

Advantages of Mediator Pattern

• Reduces direct dependencies between components, making the system easier to manage.
• Promotes reusability as objects do not have explicit dependencies on one another.
• Enhances scalability since adding new components requires minimal changes.
• Improves maintainability by centralizing communication logic.

How CQRS and Mediator Work Together

CQRS benefits from the Mediator pattern because it helps implement the separation of commands and queries in a clean, maintainable way. Here’s how they work together:

1. Handling Commands with a Mediator:

• In a CQRS-based system, commands represent actions that modify application state.
• The Mediator pattern is often used to process these commands by delegating them to appropriate handlers.
• This ensures that the sender (e.g., API controller) does not need to know which handler processes the command, leading to better decoupling.

2. Processing Queries with a Mediator:

• Similar to commands, queries can also be handled using the Mediator pattern.
• A query is sent through the mediator, which forwards it to the appropriate query handler.
• This improves code organization by centralizing query execution logic.

3. Decoupling Components:

• The combination of CQRS and the Mediator pattern ensures that components remain loosely coupled.
• Instead of controllers or services being tightly bound to specific handlers, they rely on the mediator to dispatch messages dynamically.

Benefits of Using Mediator with CQRS

• Improved Maintainability: By decoupling request senders from handlers, the system becomes easier to modify and extend.
• Better Separation of Concerns: Commands and queries have dedicated handlers, ensuring clarity in code organization.
• Scalability: Different handlers can be independently optimized and scaled.
• Centralized Message Routing: Mediator centralizes request handling, reducing dependency chaos.

CQRS and the Mediator pattern complement each other well in designing scalable and maintainable applications. CQRS enforces a clear distinction between read and write operations, while the Mediator pattern simplifies communication between components. By using these patterns together, developers can build systems that are modular, testable, and easier to manage over time.

MediatR Library

MediatR is a lightweight, in-process messaging library for .NET applications that helps implement the Mediator pattern. It simplifies communication between objects, promoting loose coupling and maintainability. MediatR is commonly used in CQRS architectures, allowing commands and queries to be handled separately.

Installing MediatR

To use MediatR in a .NET application, install the MediatR package via NuGet:

Install-Package MediatR

CQRS Project Structure

Registering MediatR

Refer the below code in program.cs which used to register the MediatR library within an ASP.NET Core application, enabling the use of the mediator pattern for handling requests and responses.

builder.Services.AddMediatR(cfg => 
        cfg.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly()));

AddMediatR is an extension method provided by the MediatR library (version 12 and above) that registers MediatR services into the application's dependency injection container. In earlier versions, the method signature was different, and the registration process varied.

cfg => cfg.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly()) this lambda expression configures MediatR to scan the specified assembly for handlers, pre-processors, and post-processors. Assembly.GetExecutingAssembly() refers to the assembly where the code is currently running, ensuring that MediatR registers all relevant services within that assembly.

If you have a different Class Library which has MediatR related code, then you have to specify that.

Project Structure for CQRS Pattern

Here, we are dealing with the Vertical Slice Architecture, so we isolate components related to a specific feature. The following is the class structure when we are using the CQRS pattern in the Pet feature:

PetCommands:

• Defines command objects that encapsulate write operations (e.g., AddPetCommand, UpdatePetCommand, DeletePetCommand).
• Commands represent intentions to change state.

PetCommandHandler:

• This class is responsible for handling commands related to pets.
• It implements business logic for executing commands such as adding, updating, or deleting a pet.
• Works in conjunction with PetCommands.cs.

PetQueries:

• Defines query objects that encapsulate read operations (e.g., GetPetByIdQuery, GetAllPetsQuery).
• Queries do not modify data; they only retrieve it.

PetQueryHandler:

• Handles queries by fetching required data from the database or another source.
• Works with PetQueries.cs to provide responses for read requests.

How These Classes Work Together

• The Command and Query separation ensures that modifications (commands) and retrievals (queries) are handled independently.
• The Handlers (CommandHandler & QueryHandler) contain the business logic for executing commands and queries.
• The PetEndpoints.cs file integrates the handlers with API routes, exposing the functionality as HTTP endpoints.
• The PetDto.cs ensures data is properly formatted when transferred between layers.

Refer the above diagram to get a clear idea on how CQRS pattern works related to the pet feature. I will use single database to make thigs simpler, rather than using write and read databases.

Let’s do the CQRS implementation in the next post. Happy coding!