Clean Code Architecture with Mediator & CQRS pattern in .Net Core

 May be for some of you, The Mediator pattern is known but here my focus is to using the Mediator pattern with CQRS (Command and Query Responsibility Segregation) pattern to make our .net core (API or web) code cleaner, extensible and maintainable.

We often see, In complex project when the dependencies are increased then our controller gets overloaded and tightly coupled with dependent services while using the built-in IoC container provided by ASP.NET Core.
Take a scenario example as Loan Application approval process. In this case, loan approval has to go through various process such as:
1. CIBIL Score checks: ; 2. Employment Status check: ; 3. Account Details validation: ; 4. Payment History: ; 5. EMI to Income Ratio check etc.
And assume in this case, all five processes are as different services and we have a web api endpoint loan application approval process to perform the loan approval. Our code will look like this:

[ApiController]
    [Route("[controller]")]
    public class LoanProcessController : ControllerBase
    {
        private ICibilService _cibilService;
        private IEmploymentService _employmentService;
        private IAccountService _employmentService;
        private IPaymentService _paymentService;
        private IEMIService _emiService;public LoanProcessController(ICibilService cibilService, 
            IEmploymentService employmentService,
            IAccountService accountService,
            IPaymentService paymentService,
            IEMIService emiService)
        {
            _cibilService = cibilService;
            _employmentService = employmentService;
            _accountService = accountService;
            _paymentService = paymentService;
            _emiService = emiService;
        }[HttpGet(Name = "GetWeatherForecast")]
        public async Task<IEnumerable<LoanApplication>> ApproveLoan()
        {
            _cibilService.ValidateCibilScore();
            _employmentService.ValidateEmployeeStatus();
            _accountService.ValidateAccount();
            _paymentService.ValidatePaymentHistory();
            __emiService.ValidatePaymentEMIPaymentRatio();
        }
    }

This is where we need a mediator to decouple the multiple services dependencies on controller. Hence the above code must be refactored using mediator pattern and it should be like as:

Seems easy going in implementation but this become more easy to implement with MediatR Extensions for Microsoft Dependency Injection with CQRS pattern.

Pardon me as I’m going to show you a simple example instead of creating a big example to depict the above scenario. Here I’m going to tweak the weather forecast sample application to demonstrate the mediator pattern with CQRS.

To follow me with this example, create a web api project using the web api template in .Net 6. This template will create weather forecast api for you and then lets follow the below steps to implement MediatR with CQRS to retrieve the weather forecast.

Step 1: Install the MediatR nugets.

Step 2: Create the CQRS folder structure to separate our your commands and queries related classes.

Command folder is for commands related to state change operations like create, update, delete etc.
and the Query folder is for queries requests like read which in general doesn’t change the state of data.

“Based on our above loan approval, probably CQRS pattern would be overthought pattern hence can be avoided simply and steak to mediator pattern only.

Step 3: Register the mediatR service

builder.Services.AddMediatR(Assembly.GetExecutingAssembly());

Step 4: Create query request and handler

using MediatR;namespace CQRSWebAPIDemo.CQRS.Query
{
    public class GetWeatherForecastQueryRequest : IRequest<IEnumerable<WeatherForecast>>
    {
        private static readonly string[] Summaries = new[]{
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
        };
        public DateTime DateTime { get; set; }public class GetWeatherForecastQueryHandler : IRequestHandler<GetWeatherForecastQueryRequest, IEnumerable<WeatherForecast>>
        { 
            private ILogger<GetWeatherForecastQueryHandler> _logger;public GetWeatherForecastQueryHandler(ILogger<GetWeatherForecastQueryHandler> logger)
            {
                _logger = logger;
            }public async Task<IEnumerable<WeatherForecast>> Handle(GetWeatherForecastQueryRequest query, CancellationToken cancellationToken)
            {
                var dateTime = query.DateTime;
                return Enumerable.Range(1, 5).Select(index => new WeatherForecast
                {
                    Date = dateTime.AddDays(index),
                    TemperatureC = Random.Shared.Next(-20, 55),
                    Summary = Summaries[Random.Shared.Next(Summaries.Length)]
                }).ToArray();
            }
        }
    } 
}

Syntax for creating a Query or command request is as:
public class {Command_Query_request_name} : IRequest<{response_type}>
you should define all your request parameter here, for an example purpose I have added DateTime for request as input.

similarly the syntax for command handler is as:
public class {handler_Name} : IRequestHandler<{Command_Query_request_name type}, {response_type}>

Step 5: Go to WeatherForecast controller and modify the code to call through mediator command.

using CQRSWebAPIDemo.CQRS.Query;
using MediatR;
using Microsoft.AspNetCore.Mvc;namespace CQRSWebAPIDemo.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private readonly ILogger<WeatherForecastController> _logger;
        private IMediator _mediator;public WeatherForecastController(IMediator mediator, ILogger<WeatherForecastController> logger)
        {
            _logger = logger;
            _mediator = mediator;
        }[HttpGet(Name = "GetWeatherForecast")]
        public async Task<IEnumerable<WeatherForecast>> Get()
        {
            return await _mediator.Send(new GetWeatherForecastQueryRequest { DateTime = DateTime.Now });
        }
    }
}

Step 6: We are done, You can now run and validate.

Conclusion:
The mediator pattern with CQRS structure is a great pattern to reduce the dependencies and make code clean within your application which helps you to reuse your components and also to keep you in line with the Single Responsible Principle.

You can also use the Command process pipeline using Mediator pattern to invoke a command handler. Or you can use messaging service as part of pipeline too for microservice api architecture design.

Reference:
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-application-layer-implementation-web-api

Hope you like it, Don’t forget to like/comment and follow me to get more like this. Thank You.

Clean Code is an Art

 Good Code vs Bad Code, “A code, understood by the machine but not human is an example of Bad code even it is giving the right output whereas a code, understood by machine and human both is the Good code”. So I would say, An expert may write code but only an artists (Code Artist) can write good code. Remember “writing a clean & good code is nothing less than an Art”.

Writing clean code is the equal responsibility of everyone in the team. Here I’m going to put some best industry practices to make your code clean and I’ll also put some points which helps to make your code clean based on my experiences so far.

Clean Code best practices:

1. Meaningful Names: Meaningful & Readable names in programming are as important as your name. Name is the first identity which speaks a lot i.e. a human name itself reveals its gender, religion, country/state (many cases) etc. And if you come to India, a person name can itself reveal about person birth place too. So isn’t it would be good to give a good name, i.e.

int c = 0; \\counter value
DateTime dt;

Here in above example, variable name c & dt doesn’t reveal anything hence it would be much better if we do this, as this says what is this variable for:

int counter = 0; 
DateTime systemGeneratedDate;

Overall goal is, name itself should speak about the purpose and the same applicable to any objects (function/class/variable) name in your program.

For classes and objects, make sure it is a noun or noun phrase and avoid using verbs or adding unnecessary prefix or suffix. i.e.

class Customer
{
}is better thanclass CustomerDetails
{
}

Similarly for functions, the name of the function must tell the purpose of the function. i.e.

public DateTime GetPlannedScheduledDate()
{
    return plannedScheduledDate;
}is better than the below function here:public DateTime GetDate()
{
     return plannedScheduledDate;
}

So please mind it and don’t be lazy for choosing a good name.

2. Functions: Function is the another key tool to create your code art. Yes, what I mean is Your function should not only have a meaningful name but it should also be short and must be doing exactly the name says. So the first thumb rule for your functions is, “they should be small”. and the second rule of functions is that “they should be smaller than that”.

So Never hesitate to create a private method instead of adding few extra lines of code in the method which is not justifiable by the function name and deviate you from the function purpose.

Also I would recommend you to strict with Single Responsibility Pattern here while writing your function.

3. Comments: A code comments is very helpful to tell others about what code is doing but what if your object name and function name itself are doing that then why to comment. I won’t say commenting is bad but I guaranteed you that over the period your comment will turn to the bad and it happens because most of time during maintenance code changes but people ignore comments to update.

Is that mean, commenting is bad, of course not but if you have to do it only when it is necessarily important. i.e.

//Bad comments example//Comment:Checking if an account is currently active
if(!account.IsDeleted && account.AvailableBalance > 500 && account.lastTransactionDate > DateTime.Now.AddMonths(-3))
{ 
    //code logic
}

above code here can be refactored and comments can be avoided more meaningfully as:

if(account.checkIfAccountActive())
{ 
    //code logic
}private bool checkIfAccountActive()
{
   return !account.IsDeleted && account.AvailableBalance > 500 && account.lastTransactionDate > DateTime.Now.AddMonths(-3);
}

This refactored code looks cleaner and no comment required to understand the code here.

but there are some places where you must have to comment to avoid code being messy with any accidental changes. i.e.

//This is our best attempt to get a race condition by creating large number of threads. 
for (int counter = 0; counter < 2500; counter ++)
{
    //Code which creates a thread with every loop here.
}

Above code tells clearly the reason behind loop value to 2500. In this cases, comment is justifiable.

There are other cases also where comments are justifiable like, Legal comment (i.e. Copyrights), domain specific information (which can help programmer why certain things are written in that way) etc.

4. Code Formatting: This helps your code looks cleaner and it increases readability. Use new line space, tab space, curly braces (event if it single line if statements) etc. to format your code.

Also try to group & order the functions like public functions comes first and then private functions in a order it’s been used.

5. Lengthy Function Parameters: I never seen any strict guidelines to limit the no. of parameters in functions but lengthy or more parameters affects the code readability. Hence you must avoid to limit it as short as possible.

6. Error Handling: This is another key area where if you don’t pay much attention then it cost your program’s performance & security, but if you handle it well then it will not only help you in performance & security but also helps to debugging code when there is an error.

So key recommendation here is, use Exception Handling (try, catch, finally) efficiently and log your exceptions.

I would suggest read this article here Exception Handling Techniques & Tricks C# to know the best practices of Exception Handling.

7. Unit Tests: Unit test is extremely important to safe guard your code with any accidental change which can break the feature/purpose, this is only possible if your code is written in such a way. So before writing code, first ask yourself, can you write the unit test for this piece of code and do it. If not, it is time to refactor the code.

Now lets see few techniques which can help any teams to force to follow the above guidelines to make the code better and cleaner.

1. Peer Code Review: This is best techniques to clean your code. The more persons review your code, you get more ideas to make your code better. It is a human tangency to miss small things when you are on a problem to solve but those small things may affect the code readability, performance or security. Hence this is where Peer Code Review helps.
2. Keep yourself updated: Whatever technology or language you use, it is very important to keep yourself updated so that you can use the latest technology or features to make your code better & better. Hence thumb rule here, keep learning.
3. Use libraries (nuget packages): There are many useful open source libraries available to do which you might want to do so I recommend to use them instead of reinventing the wheel by your own. i.e. for data operations in .net there is a library called Dapper which is very useful”, so I recommend to use this instead of writing the whole piece from connection management to data management etc.
   At the same time, Be careful also while choosing the libraries and you must read the licenses or the terms & conditions.

That’s all. Hope this helps, Happy reading. Thank You

Exception Handling Techniques & Tricks C#

 Exception handling could turn to costly operation in your code if you don’t pay much attention to it.

I feel in real life, this is like driving a non-automatic (with gear) car efficiently to get good mileage and that is possible only if you use the gear shift and clutch properly or else your car will turn to fuel drinker :) . Similarly if you don’t take care of computing and memory efficiently then your program too will turn to bad in performance and exception handling plays a key role here so lets discuss about it.

1. Use Catch only if needed as it is costly operation, if possible use if instead.
   i.e. Divide by zero exception. why not do a check for zero before divide operation if possible.

try
{
    var result = myVal/someParam;
}
catch(DivideByZeroException ex)
{
    //do what you want
}above code can be refactored like below to avoid the costly catch operation.if(someParam != 0)
{
    var result = myVal/someParam;
}
else
{
    //do what you wanted to do in the catch block
}

similar situation can arises with null values too and costly exception can be avoided using null checks.

2. You must ignore catching exception if you are not handling it. Though in some catch it may be necessary when you want to ignore the exception as fallback mechanism.

try
{
     //code
}
catch(Exception)
{
}
return something;

In above example it is certainly not a good practice unless there is a unavoidable circumstance to do so. In this case if possible to avoid the catch with check please do so, or even if there is possibility where caller of this handling the exception then leave it to them instead of catching here.

3. Like above point, also avoid throw if not necessary. Consider below examples where certainly throw is not necessary.

try
{
     //code
}
catch(Exception ex)
{
     throw ex;
}
return something;ORtry
{
     //code
}
catch(Exception)
{
     throw;
}
return something;

In above example, programmer is not caring or respecting the exception but still handling it throw it back to the caller, why to do so when the catch is avoided here. In any case caller of this block is expecting an exception as code says so let it go as it is and remove the try catch completely.

4. In case if and there is a need, where we need to process the exception in above example (like logging or handling fallback mechanism etc) then throw an exception then use throw only instead of throw ex to save the stack trace info.

//Bad Code
try
{
     //code
}
catch(Exception ex)
{    
     //do something
     throw ex;
}
return something;//better Code
try
{
     //code
}
catch(Exception ex)
{    
     //do something
     throw;
}
return something;

Above code scenario can be refactored well to avoid throw and rely on return.

5. Avoid dirty Nested try catch. lets see the example.

//Bad code
try
{
     //some code
     try //inner try catch 1
     {
         //some code
     }
     catch(Exception ex)
     {
         throw ex;
     } 
     try  //inner try catch 2
     {
         //some code
     }
     catch(Exception ex)
     {
         throw;
     }
}
catch(Exception ex)
{  
    //code to handle the exception
}

Above example can not be justified even though inner try catch block is the demand of program nature. This example code must be refactored as.

{
       method1();
       method2();
}private void method1()
{
     try //inner try catch 1
     {
         //some code
     }
     catch(Exception ex)
     {
        //Handle exception and do not throw back to caller.
     }
}private void method2()
{
     try //inner try catch 1
     {
         //some code
     }
     catch(Exception ex)
     {
        //Handle exception and do not throw back to caller.
     }
}

OR

try
{
    method1();
    method2();
}
catch(NullException ex)
{ 
    //Handle exception. If needed catch can be classified well based   on the exception type behavior of method1 and method 2.
}
catch(Exception ex)
{ 
    //Handle exception
}private void method1()
{
     //code
}private void method2()
{
     //code
}

Any way the final goal of the code refactoring should be “avoiding multiple catch blocks”.

6. Use the finally block to respect the caller. This is very powerful features which can and must be used to cleanup your mess instead making it tough for the caller.

{
       var result = method1();
       method2();
}private int method1()
{  
     int result;
     try //inner try catch 1
     {
         //some code
     }
     catch(Exception ex)
     {
        //Handle exception and do not throw back to caller.
     }
     finally
     { 
        result = 0;
     } 
     return result;
}private void method2()
{
     try //inner try catch 1
     {
         //some code
     }
     catch(Exception ex)
     {
        //Handle exception and do not throw back to caller.
     } 
     finally
     { 
        //clean your mess-ups, like closing the open connection,  fallback mechanism etc.
     }
}

7. Use Custom Exceptions. This is very important feature to avoid letting caller know the internal root cause failure for code security as the stack trace has lot of information.

//Bad Practice
public Result PerformAction()
{
     try
     {
     }
     catch(Exception ex)
     {
          throw;
     }
}//Good Practice
public Result PerformAction()
{
     try
     {
     }
     catch(Exception ex)
     {
          return new CustomException("An internal error occured");
     }
}public class CustomException : Exception
{
}

8. Last but not least, Never forget to handle any uncaught exception in your Gateway/Entry/Main method. i.e.
if you are in .Net Core, use the middleware or filters to handle uncaught exception generically. Follow the article “Middleware and Filters power in ASP.NET Core” to know more about Middlewares and Filters.

Hope you enjoyed reading. Thank You.

Anti-corruption Layer pattern a life saver

 Anti-corruption layer pattern allows communication between one system or subsystem to another system or sub system without corrupting each other system domain or model or the objectives.

Technically Anti-corruption layer is made of multiple different patterns like Facade and Adapter Pattern. Layer can have own set of patterns to satisfy the need but here I’m going to take an example where I’ll be using most popular patterns Facade and Adapter to build the Anti-Corruption layer.

Problem: Assume we have a legacy Banking system and we plan to upgrade the system gradually or adding new enhancements.

Challenge: Being the system legacy doesn’t allows us to be inline with latest technology stack easily. For simplicity assume, the legacy system has set of API services which is interacting using SOAP. i.e.

Now we have a challenge with upgrading the system. i.e. converting the individual services (gradually all) to REST services OR having a new Client system (an mobile app) relying on REST and allows the communication with the legacy system. Lets see how we can solve the problem using Anti-Corruption layer pattern and how we can build the layer without affecting the existing legacy and live with the both the system New and Legacy.

Solution: Assume we have a new client application which can only deal with REST APIs. Hence we need a bridge which can help to enable the communication between new and legacy without affecting the each other system. So this is what we can do by building Anti-Corruption Layer using Facade and Adapter patterns.

As per above diagram, We have three components in our Anti-Corruption Layer and they are:

1. Rest API Layer: REST APIs for different services. We need this as our new system can deal with only REST protocols.
2. Adapter Pattern: This layer will help us to translate the message between two different protocols REST & SOAP.
3. Facade Layer: This layer will actually make the SOAP calls to the legacy.

With this approach we solve the problem without making any change to the legacy system.

The Anti-Corruption layer here, can be implemented as a component within the application or as an independent service and can be hosted independently. In benefit, it can manage the traffic by its own and can be scaled in or out accordingly.

Pros & Cons of the Anti-Corruption layer pattern:
Cons: Because of the added extra added layer, this may add latency to calls made between the two systems and also it’s introducing extra services which should be managed & maintained apart from the system

Pros: Easily allows to enable the interaction between two systems which are not compatible to each other with without corruption their domain, model and objectives.

Considerations:
1. Consider if you need one or more Anti-Corruption layers.
2. Consider the effort and plan from development to release and then maintenance of this.
3. Consider the hosting plan, whether this could be a standalone component and then taking care of scaling Or this will be a part of existing system.
4. Decide if this would be temporary or permanent or will be retired after all legacy functionality has been migrated and plan accordingly.

When to use this pattern

Use this pattern when:

• A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be maintained.
• Two or more subsystems have different semantics, but still need to communicate.

This pattern may not be suitable if there are no significant semantic differences between new and legacy systems.

Hope you like it. Thank You for reading.
Reference: https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer