Vertical Slice Architecture

Layered architectures are the base of many software systems, but they group the system by technical layers, which don’t always work closely together. What if you wanted to organize the system around features and ensure all parts of a single feature are closely linked? In this article, we will discuss Vertical Slice Architecture, which does exactly that organizing the system around features.

Drawback of Layered Architecture

Layered architectures split the software into different layers or tiers, with each layer often being its own project for example N-tier and Clean architecture. This approach makes the system easier to understand and maintain, offering benefits like maintainability, flexibility, and loose coupling.

However, layered architectures can be restrictive because the dependencies between layers are fixed. For example, in Clean Architecture:

• The domain has no dependencies
• The application layer can reference the Domain
• Infrastructure can reference both Applications
• Domain and Presentation can reference both Application and Domain

This setup leads to high coupling within layers and low coupling between them, which increases complexity due to many abstractions that need to be maintained.

What is Vertical Slice Architecture

Vertical Slice Architecture is a design approach where a system is divided into vertical slices, each representing a feature or a specific functionality of the application. Unlike traditional layered architecture, where the system is split into horizontal layers (e.g., presentation, business logic, data access), vertical slices focus on delivering complete features from the UI down to the database.

Each slice in this architecture contains everything needed to implement a specific feature, including:

• Controllers (or API endpoints)
• Application logic
• Domain logic (business rules)
• Data access logic

This approach promotes separation of concerns and allows for better scalability and maintainability. It also aligns with Domain-Driven Design (DDD) by focusing on the business domain.

Here’s an example of a folder structure in a .NET Core Web API project following the Vertical Slice Architecture.

📁-- Features/
	📁 -- CreateOrder/
		📁-- CreateOrderRequest.cs
		📁 -- CreateOrderHandler.cs
		📁 -- CreateOrderResponse.cs
		📁 -- CreateOrderController.cs
	📁-- GetOrder/
		📁 -- GetOrderRequest.cs
		📁 -- GetOrderHandler.cs
		📁 -- GetOrderResponse.cs
		📁 -- GetOrderController.cs 

Each vertical slice typically includes:

• Request: A class representing the input data for the slice (e.g., a DTO).
• Handler: A class responsible for handling the request, containing the business logic.
• Response: A class representing the output data (e.g., a DTO or ViewModel).
• Controller: The API endpoint that interacts with the request and response classes.

Here’s how you can visualize vertical slices:

Benefits of Vertical Slice Architecture

1. Feature Isolation: Each slice is self-contained, making it easier to understand and modify specific features without impacting the entire system.
2. Scalability: As features are isolated, teams can work on different slices independently, enabling parallel development and deployment.
3. Testability: Since each slice is independent, it’s easier to write and maintain unit and integration tests.
4. Flexibility: You can use different technologies or patterns for different slices if needed, adapting to the specific needs of each feature.

The best part is you can remove or disable any feature at any time if it’s not needed. Simply exclude it from the project, build the application, and run it. This won’t cause any problems because the removed feature is not linked to any other feature, as all features are independent.

Read – CQRS implementation with Vertical Slice Architecture using Mediator. This article explains how to implement Vertical Slice Architecture in CQRS design pattern with Mediator using Mediatr library, in asp.net core Web API application.

What is CQRS?

CQRS, short for Command Query Responsibility Segregation, is a design pattern that separates the application’s read and write operations into two parts – commands (write operations) and queries (read operations). This segregation allows for more flexible and scalable systems, particularly in complex applications or rapidly changing business requirements, where the read & write operations differ significantly.

1) Commands are actions that change the state of the system, by performing Create(), Update() and Delete() operations.

The command pattern consists of two objects:

• Command – Defines which methods should be executed.
• Command Handler – responsible for processing commands, which are requests to perform actions that change the state of the system.

2) Queries are actions that retrieve read-only data from the system without changing its state, for example, Get() operation. It doesn’t alter the data, just fetches it.

The query pattern consists of two objects:

• Query – Defines the objects to be returned.
• Query Handler – responsible for processing queries, which are requests to retrieve data from the system.

Why Use CQRS?

It’s common to see traditional architectural patterns that use the same data model or DTO for querying and persisting data and handle a significant volume of read-and-write operations. This approach works well for simple CRUD operations, but as the number of users, the volume of these operations and the complexity of the system increases, the application may encounter performance, scalability, and flexibility challenges.

The primary goal of CQRS is to use different data models effectively, providing flexibility in scenarios that require a complex structure. It allows you to create multiple DTOs without breaking architectural principles or risking data loss.

You can implement CQRS using Mediator (MediatR library) in .Net.

What is Mediator?

The Mediator is a behavioral design pattern that facilitates communication between different components or objects in a system by centralizing this interaction through a mediator object. Instead of components communicating directly with each other, which can lead to a tightly coupled and complex system, they interact with the mediator, which handles the communication and coordination between them.

In short, Mediator makes a bridge between different objects, which eliminates the dependency between them as they do not communicate directly.

In .NET Core, the Mediator pattern is often implemented using the MediatR library, which is a popular library for implementing this pattern. When using MediatR, you create a request (like a command or query) and a corresponding handler. The request is sent to the mediator, which then routes the requests to their respective handlers.

Pros: Independence between different objects, Centralized communication, and Easy maintenance.

Cons: Greater complexity, and it can become a bottleneck in an application if it has to handle a large amount of data.

CQRS and Mediator Implementation

Let’s create a simple Web API project and understand the basic implementation of CQRS design pattern using MediatR library, step-by-step.

1) Create a new ASP.NET Core Web API project in Visual Studio.

2) Add project Dependencies in .csproj file or via NuGet package manager.

<PackageReference Include="MediatR" Version="12.4.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="8.0.8" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="8.0.8" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="8.0.8"> 

3) Create the Entity Model: For demonstration purposes, create a Model class called “EmployeeModel” and add these 5 fields – Id(primary key), Name, Gender, RoldId, EmailId. This entity model will be passed to Entity Framework to make database changes.

4) Create DTO (Data Transfer Object) for “EmployeeModel” model, and name that class as “EmployeeDTO“. DTOs usually include only the data required by the client, excluding any unnecessary or sensitive information.

5) Create the Database Context: Add new class called “ApplicationDbContext” and add the following code:

using Microsoft.EntityFrameworkCore;

namespace Infrastructure;

public sealed class ApplicationDbContext : DbContext
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options)
    {
    }

    public DbSet<EmployeeModel> Employees { get; set; }
} 

6) Add required services to the Program.cs file.

// Adding the MediatR dependency
builder.Services.AddMediatR(m=> m.RegisterServicesFromAssemblies(typeof(Program).Assembly));

builder.Services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection"))
    ); 

7) Run EF Core Commands (Add-Migration)

You can run the following commands from the ‘Package Manager Console’ in Visual Studio:

• Add-Migration InitialModel
• Update-Database

Alternatively, you can run the commands below in a project root terminal.

• dotnet ef migrations add InitialModel
• dotnet ef database update

8) Implement the CQRS design pattern

We will follow the Vertical Slice Architecture approach to organize our folder structure by feature.

Create a new folder called “Employee” under “Features” folder and inside it create two new folders “Commands” and “Queries.”

Inside the Commands and Queries folders, create a folder for each function you need to execute like Create, Read, Update, and Delete operations. See the folder structure below, organized by feature-wise.

9) Create the Query/Command class: Create a Handler for each Query/Command class, follow the code given below:

Create Queries

a. Get All Employees:

public sealed record GetAllEmployeeQuery : IRequest<List<EmployeeDTO>>
{
} 

public sealed record GetAllEmployeeQueryHandler : IRequestHandler<GetAllEmployeeQuery, List<EmployeeDTO>>
{
    public GetAllEmployeeQueryHandler(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    private readonly ApplicationDbContext _dbContext;

    public async Task<List<EmployeeDTO>> Handle(GetAllEmployeeQuery request, CancellationToken cancellationToken)
    {
        return await _dbContext.Employees
            .AsNoTracking()
            .Select(s=> new EmployeeDTO
            {
                Id = s.Id,
                Name = s.Name,
                EmailId = s.EmailId,
                Gender = s.Gender,
                RoleId = s.RoleId   
            })
            .ToListAsync(cancellationToken);
    }
} 

b. Get Employee By Id:

public sealed record GetEmployeeByIdQuery(int Id) : IRequest<EmployeeDTO>
{
} 

public sealed record GetEmployeeByIdQueryHandler : IRequestHandler<GetEmployeeByIdQuery, EmployeeDTO>
{
    public GetEmployeeByIdQueryHandler(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    private readonly ApplicationDbContext _dbContext;

    public async Task<EmployeeDTO> Handle(GetEmployeeByIdQuery request, CancellationToken cancellationToken)
    {
        var result = await _dbContext.Employees
            .AsNoTracking()
            .FirstOrDefaultAsync(w => w.Id == request.Id, cancellationToken);

        return new EmployeeDTO
        {
            Id = result.Id,
            Name = result.Name,
            EmailId = result.EmailId,
            Gender = result.Gender,
            RoleId = result.RoleId
        };
    }
} 

Create Commands

a. Create Employee:

public sealed record CreateEmployeeCommand(EmployeeDTO EmployeeDTO) : IRequest<EmployeeDTO>
{
} 

public sealed record CreateEmployeeCommandHandler : IRequestHandler<CreateEmployeeCommand, EmployeeDTO>
{
    public CreateEmployeeCommandHandler(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    private readonly ApplicationDbContext _dbContext;

    public async Task<EmployeeDTO> Handle(CreateEmployeeCommand request, CancellationToken cancellationToken)
    {
        var employee = new EmployeeModel
        {
            Name = request.EmployeeDTO.Name,
            Gender = request.EmployeeDTO.Gender,
            EmailId = request.EmployeeDTO.EmailId,
            RoleId = request.EmployeeDTO.RoleId,
        };

        _dbContext.Employees.Add(employee);
        await _dbContext.SaveChangesAsync(cancellationToken);
        return request.EmployeeDTO;
    }
} 

b. Update Employee:

public sealed record UpdateEmployeeCommand(EmployeeDTO EmployeeDTO) : IRequest<EmployeeDTO>
{
} 

public sealed record UpdateEmployeeCommandHandler : IRequestHandler<UpdateEmployeeCommand, EmployeeDTO>
{
    public UpdateEmployeeCommandHandler(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    private readonly ApplicationDbContext _dbContext;

    public async Task<EmployeeDTO> Handle(UpdateEmployeeCommand request, CancellationToken cancellationToken)
    {
        var employee = new EmployeeModel
        {
            Id = request.EmployeeDTO.Id,
            Name = request.EmployeeDTO.Name,
            Gender = request.EmployeeDTO.Gender,
            EmailId = request.EmployeeDTO.EmailId,
            RoleId = request.EmployeeDTO.RoleId,
        };

        _dbContext.Employees.Update(employee);
        await _dbContext.SaveChangesAsync(cancellationToken);
        return request.EmployeeDTO;
    }
} 

c. Delete Employee:

public sealed record DeleteEmployeeCommand(int id) : IRequest
{
} 

public class DeleteEmployeeCommandHandler : IRequestHandler<DeleteEmployeeCommand>
{
    public DeleteEmployeeCommandHandler(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    private readonly ApplicationDbContext _dbContext;

    public async Task Handle(DeleteEmployeeCommand request, CancellationToken cancellationToken)
    {
        var employee = await _dbContext.Employees.
            Where(w=> w.Id == request.id).
            FirstOrDefaultAsync(cancellationToken);

        if (employee != null)
        {
            _dbContext.Employees.Remove(employee);
            await _dbContext.SaveChangesAsync(cancellationToken);
        }
    }
} 

10) Create API endpoints: Now we have all the required commands/queries and handlers in place, let’s wire them up with APIs. For this demonstration, we will use a controller named “EmployeeController” to implement CRUD operations, each of which will execute the corresponding query or command handler via MediatR. You can use other mechanisms like Minimal API to configure endpoints.

public class EmployeeController : Controller
{
    private IMediator _mediator;
    protected IMediator Mediator => _mediator ??= HttpContext.RequestServices.GetService<IMediator>();


    [HttpGet("GetAll")]
    public async Task<IActionResult> GetAllEmployee(CancellationToken cancellationToken)
    {
        var query = new GetAllEmployeeQuery();
        return Ok(await Mediator.Send(query, cancellationToken));
    }

    [HttpGet("GetById/{id}")]
    public async Task<IActionResult> GetEmployeeById(int id, CancellationToken cancellationToken)
    {
        var query = new GetEmployeeByIdQuery(id);
        return Ok(await Mediator.Send(query, cancellationToken));
    }

    [HttpPost("Create")]
    public async Task<IActionResult> CreateEmployee([FromBody] EmployeeDTO request, CancellationToken cancellationToken)
    {
        if (!ModelState.IsValid) { 
            return BadRequest(string.Join(Environment.NewLine, ModelState.Values
                                        .SelectMany(x => x.Errors)
                                        .Select(x => x.ErrorMessage))); }

        var command = new UpdateEmployeeCommand(request);
        return Ok(await Mediator.Send(command, cancellationToken));
    }

    [HttpPut("Update")]
    public async Task<IActionResult> UpdateEmployee([FromBody] EmployeeDTO request, CancellationToken cancellationToken)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest(string.Join(Environment.NewLine, ModelState.Values
                                        .SelectMany(x => x.Errors)
                                        .Select(x => x.ErrorMessage)));
        }

        var command = new UpdateEmployeeCommand(request);
        return Ok(await Mediator.Send(command, cancellationToken));
    }

    [HttpDelete("DeleteById/{id}")]
    public async Task<IActionResult> DeleteEmployee(int id, CancellationToken cancellationToken)
    {
        var command = new DeleteEmployeeCommand(id);
        await Mediator.Send(command, cancellationToken);
        return Ok();
    }
} 

11) Test the Endpoints via Swagger: The implementation is complete. Now, let’s test it using Swagger! Build and run your ASP.NET Core application and open the Swagger UI. The screenshots below display the API test results from Swagger. You can also use other Web API testing tools like Postman, Fiddler, etc.

adding a new record – screenshot

getting a record by id – screenshot

Conclusion

We learned how CQRS and the Mediator pattern work, explored how to implement them using the MediatR library, and also covered Entity Framework Core and the Vertical Slice Architecture approach in a .NET 8 Web API.

In this article, we will learn about the Domain-Driven Design pattern and get a basic idea of how to organize the layers and what components each layer can have, for building robust enterprise applications.

What is Domain Driven Design (DDD)?

DDD is a software development architecture-style approach that tells you how to manage your domain complexity.

Eric Evans is the author of “Domain-Driven Design: Tackling Complexity in the Heart of Software” which introduced and elaborated on the principles & practices of Domain-Driven Design (DDD), published in 2003.

DDD is only intended for large projects, like more than 6 or 8 months, with large complexity. Domain refers to the subject area around which the application that is being developed is centered. For example, the topic/domain could be “online order processing” which you can use to develop an Online Shopping Application. It can have multiple domains like delivery, transport and others within the same application.

The goal of implementing DDD is to handle complex scenarios so that domain experts and developers can collaborate effectively with minimal misunderstanding and arguments.

Pros:

• Simple communication: Communication between developers & experts becomes much easier
• Object-oriented: DDD is Object-oriented which gives more flexibility, the entire system can be modified & improved regularly.
• Structured Complexity: By breaking down the domain into smaller, manageable parts (entities, value objects, aggregates, etc.), DDD helps in managing the inherent complexity of large systems.
• Bounded Contexts: DDD encourages defining clear boundaries for different parts of the system, known as bounded contexts, which isolate different domains and reduce dependencies.
• Clear Separation of Concerns: By organizing code around the business domain, DDD ensures that changes in business logic are localized, reducing the risk of unintended side effects.
• Test-Driven Development (TDD): DDD naturally complements TDD by encouraging the development of small, focused units of code that are easy to test.

Cons:

• Domain knowledge required: There has to be at least one domain specialist who understands the precise characteristics of the subject that’s at the center of the application
• Doesn’t work for highly technical projects: DDD is perfect for applications that have complex business logic, not which is highly technical.

Domain Driven Design – Folder Structure

Let’s look at the diagram above to understand how to create folder structures and see what files can go in each folder.

Note: These structures/ components can be different for each application depending on business needs, so you can change them as needed.

Domain:

	📁 Abstractions 
		📁 Repositories
			- IRepository
			- IUnitOfWork.cs

	📁 Errors
		- DomainErrors.cs (static error classes)

	📁 Enumerations
	
	📁 Exceptions
		- BadRequestException.cs
		- NotFoundException.cs

	📁 Models/Entities
		- EmployeeEntity.cs

	📁 Primitives
		- JsonResult.cs

	- AssemblyReference.cs


Application:
// ProjectReference = Domain.csproj

	📁 Behaviours
		- ValidationBehaviours.cs

	📁 Exceptions

	📁 Errors
		- ValidationErrors.cs (static error classes)

	📁 Features (Vertical Slice Architecture)
		📁 Feature1[Employee] (CQRS Design Pattern using MediatR)
			📁 Command
				📁 Create
					- CreateEmployeeCommand.cs
					- CreateEmployeeCommandHandler.cs
			📁 Queries
				📁 GetAll
					- GetAllEmployeeQuery.cs
					- GetAllEmployeeQueryHandler.cs

	- AssemblyReference.cs				


Infrastructure:
// ProjectReference = Domain.csproj

	📁 Authentication
		- JwtProvider.cs
		- JwtSettings.cs

	📁 Configurations
	
	📁 Emails
		- MailSettings.cs
		- EmailService.cs

	📁 Logging

	📁 Messaging
		- MessageSettings.cs

	📁 Notifications
		- EmailNotificationService.cs

	📁 Migrations
		- ApplicationDbContextModelSnapshot.cs

	📁 Repositories
		- EmployeeRepository.cs
		- GenericRepository.cs

	- ApplicationDbContext.cs

	- AssemblyReference.cs

	
Presentation:
// ProjectReference = Application.csproj

	📁 Controllers
		- EmployeeController.cs

	- AssemblyReference.cs


Web:
// ProjectReference = Infrastructure.csproj
// ProjectReference = Presentation.csproj

	📁 Middleware
		📁 ExceptionHandling.cs 

• The Domain Layer is the core of the application, containing the business logic and rules. It represents the fundamental business concepts and behaviors, value objects, rules, abstractions, base classes, etc.
• The Application Layer coordinates the application’s activities, serving as a mediator between the domain layer and the presentation/infrastructure layers. It doesn’t handle business rules but coordinates tasks using domain objects.
• The Infrastructure Layer provides technical capabilities to support the other layers. It handles concerns such as data persistence, messaging, logging, and external integrations.
• The Presentation Layer is responsible for the user interface and interaction. It handles the display of information and user input, interacting with the application layer to execute commands and retrieve data. For example controllers or User Interfaces (UI) or any front-end interface

To support Dependency Injection you need to define all of your service registration inside the Web application. The web applications will have access to the controllers that are defined in the Presentation layer and will have access to anything that is defined inside our application.

Note: Don’t put the Controller directly in the Web application. If you do, it can access the Infrastructure project, for example allowing direct database access using something like _dbcontext. This breaks the CQRS pattern for separating read/write operations, making it impossible to enforce the proper architecture. Instead, place the Controller in the Presentation Class library, where we can control all the libraries we are referencing.