Introduction to Vertical Slices Architecture

Learn How to Structure Your Solution with Vertical Slices Architecture

In Today’s Episode…

We’re going to take a look at how we can build a solution with Vertical Slices Architecture. In the realm of software development, structuring your project effectively can significantly influence the success and maintainability of your application.

Among the various architectural styles, Vertical Slices Architecture has emerged as a compelling approach, particularly for complex applications. This blog post aims to provide an in-depth understanding of Vertical Slices Architecture, its benefits, and how it compares to traditional architectures, using a real-world .NET application as an example.

I will also provide an approach that I find effective, but it's not the only way of doing it. There are many ways to implement Vertical Slices Architecture, and the right choice depends on the specific needs and context of your project. The goal is to illustrate a practical example that you can adapt and modify to suit your own requirements.

Traditional Layered Architecture

In traditional layered architecture, the application is divided into horizontal layers based on technical concerns. This means organizing your code into separate sections like:

1. Presentation Layer: This layer handles everything related to the user interface. It’s responsible for displaying information to the user and interpreting user inputs.

2. Business Logic Layer (Application & Domain): This layer contains the core functionality of the application. It’s where the main business rules and operations reside.

3. Data Access Layer: This layer is responsible for interacting with the database. It includes code for querying, updating, and managing the data.

Imagine you're building an application for managing a library. In a traditional layered architecture, you might have one layer handling all the user interactions (like searching for books), another layer handling the business rules (like determining if a book can be borrowed), and yet another layer for accessing the database (like retrieving book details).

Pros:

• Separation of Concerns: Each layer has a distinct responsibility, making the code more organized.

• Reusability: Common functionalities can be reused across multiple features.

Cons:

• Tight Coupling: Changes in one layer often require changes in others, leading to a fragile codebase.

• Difficulty in Maintenance: Understanding and modifying features that span multiple layers can be challenging.

• Slower Development: Coordination between layers can slow down the development process.

Vertical Slices Architecture

Vertical Slices Architecture organizes code by feature rather than by technical concern (such as controllers, services, repositories, etc.). This approach ensures that all the necessary components for a specific feature are grouped together, forming a "vertical slice" of the application. Each slice includes everything from the user interface to the database access, encapsulating the complete functionality for that feature.

To illustrate this, let's revisit our library management application example, but this time, we'll structure it using Vertical Slices Architecture.

In a traditional layered architecture, you might have separate layers for handling user interactions, business logic, and data access. In contrast, with Vertical Slices Architecture, you would organize your code into slices based on features, such as "Book Borrowing" and "Book Returning".

Here’s how the "Book Borrowing" feature might be structured:

1. Features/BookBorrowing

   • UI: Handles user interactions specific to borrowing a book.

   • Commands: Encapsulates the data and logic needed to initiate a book borrowing operation.

   • Handlers: Processes the borrowing command, enforcing business rules (e.g., checking if the book is available and the user has no overdue books).

   • Repositories: Manages the data access related to borrowing books, such as updating the book's status in the database.

   • Events: Defines events that occur during the borrowing process, such as BookBorrowedEvent.

Each of these components is self-contained within the "Book Borrowing" slice. This means that all the code required to handle borrowing a book is located in one place, making it easier to understand, modify, and maintain.

Similarly, the "Book Returning" feature would be another slice:

2. Features/BookReturning

   • UI: Handles user interactions specific to returning a book.

   • Commands: Encapsulates the data and logic needed to initiate a book returning operation.

   • Handlers: Processes the returning command, enforcing business rules (e.g., updating the book's status and checking for overdue fees).

   • Repositories: Manages the data access related to returning books, such as updating the book's status in the database.

   • Events: Defines events that occur during the returning process, such as BookReturnedEvent.

Key Benefits:

1. High Cohesion: Each feature contains all relevant components, making it easier to understand and modify.

2. Low Coupling: Features are independent of each other, reducing the risk of changes in one feature affecting others.

3. Scalability: New features can be added without impacting existing functionality.

4. Maintainability: The modular structure simplifies code navigation and maintenance.

5. Faster Development: Developers can work on different features simultaneously without interfering with each other.

6. Easier Migration to Microservices: I personally find this architecture to make my life easier when I am migrating from a single monolith codebase to microservices.

Implementing Vertical Slices Architecture

To implement Vertical Slices Architecture in a .NET application, follow these steps:

1. Identify Features: Break down the application into distinct features or functionalities.

2. Create Slices: For each feature, create a vertical slice that includes all necessary components (e.g., UI, business logic, data access).

3. Organize Code: Structure your codebase so that each slice is self-contained, with minimal dependencies on other slices.

4. Ensure Independence: Design each slice to operate independently, enabling developers to work on different slices simultaneously.

Real-World Project Structure Example

Let's take a look at a real-world project structured using Vertical Slices Architecture. There’s no single way of structuring the code, so for this example, I decided to create three separate slices, each of which has separate features in it.

For example, here (picture below) we have the Appointments feature, which includes sub-features for creating or removing appointments. I find this way of structuring to work nicely for my projects.

Each feature can contain many folders and classes, depending on the problem you’re solving. For the purpose of this demo, I decided to go with Features, Events, Models, EventHandlers, Infrastructure, and Migrations folders.

Folders and Their Uses:

• Features:

  • Purpose: Encapsulates the logic and operations related to specific functionalities within the application, such as commands and queries.

  • Why Used: Organizes business logic by feature, making it easier to maintain and evolve individual pieces of functionality.

• Events:

  • Purpose: Represents significant occurrences within the domain that other parts of the system can react to.

  • Why Used: Facilitates decoupled communication between different parts of the application, enabling a more modular design.

• Models:

  • Purpose: Defines the data structures used within the feature, including domain entities and data transfer objects (DTOs).

  • Why Used: Provides a clear definition of the data that is used and manipulated within each feature, promoting consistency and clarity.

• EventHandlers:

  • Purpose: Contains the logic for processing and reacting to domain events.

  • Why Used: Encapsulates the event handling logic, ensuring that responses to events are managed in a single, cohesive place.

• Infrastructure:

  • Purpose: Contains the components that provide technical capabilities to the application, such as database contexts and external service integrations.

  • Why Used: Keeps technical implementation details isolated from business logic, promoting a clean separation of concerns.

• Migrations:

  • Purpose: Manages database schema changes and versioning.

  • Why Used: Ensures that database schema evolution is controlled and consistent across different environments.

GitHub Project

You can check out the project structure on GitHub. This repository is always changing and never in a final state, but should give you a good idea of how to structure your project using Vertical Slices Architecture in the way that is shown in this article.

YouTube Video

I’ve created a short video demonstrating this architecture with a real project.