Solid API Refactoring With Mediator & CQRS Pattern-From Chaos to Serenity
By: Semih Şenvardar
Tags: Web Api Development, Refactoring, Dotnet Core, Cqrs, Mediator

In such cases, we can put the existing functionality in a certain order and make it more understandable with tiny touches, just as in the jenga game. Now, let’s ground this theoretical explanation with a concrete example and remove the question marks in our minds.

Real Life Example

Let’s say we have an Asp.Net Core based API application that has various RESTful calculation services. As a result of various improvements made over time, we have an API controller that looks like this:

“Before software can be reusable, it first has to be usable.” — Ralph Johnson

There are many different service modules that return payment plans, interest rates, amortization calculations and provide caching, logging and mapping solutions. While this example is not very busy and complex, real life scenerios usually get much more crowded. I felt the need to keep it a little simpler for clarity.

Logging & caching controls, mapping operations and service calls in each API method in the controller turn into blocks of code that are difficult to read and understand as time passes. In most cases, these controllers become God-classes, which is one of the main anti-patterns to avoid.

light as feather API applications

There are many different approaches to solve this situation. The one I want to focus is applying Mediator and CQRS patterns together. This approach not only simplifies our code but also complies with the SOLID principles effectively. Before looking at the implementation, let’s try to understand these patterns, though not in depth.

Mediator Pattern

Mediator Pattern, one of the behavioral design patterns, abstracts the communication between objects through the mediator object (encapsulation).

Objects cannot communicate with each other directly, communication between them is the responsibility of the mediator object. This situation decreases the dependence between objects and therefore coupling.

We can implement this design pattern with our own methods or we can use MediatR, a very popular, simple, unpretentious mediator implementation library in the .Net ecosystem.

CQRS (Command Query Responsibility Segregation)

The CQRS pattern, originally used by Greg Young as CQS, and which is its extension, generally defends the thesis that a method must either change the state of an object or return a value.

Command: It is what changes the state of an object or system. It does not return any value back.

Query: It does not change the state of the object or system. It just returns a value.

The reason we need CQRS in our refactor process is to separate the loads of read and write operations so that they can be scaled independently from each other. Keeping commands and queries in separate models can present a new consistency challenge. Compliance with DDD and Event Sourcing structures and its applicability to complex domains can be listed as the pros of this pattern.

(*In architectures where simple business rules are operated and in a world where CRUD operations suffice, use of CQRS pattern will bring unnecessary complexity. Therefore use cases need to be carefully evaluated.*)