Separation of Responsibilities in Practice: Comparison between N-Tier Architecture and Clean Architecture

Introduction

In this article, we will explore two popular approaches to separating responsibilities: N-Tier Architecture and Clean Architecture. Throughout the text, we will discuss the characteristics, advantages, disadvantages, and practical examples of each approach, so you can make informed decisions in the architecture of your applications.

N-Tier Architecture?

The N-Tier Architecture, also known as layered architecture, is an approach that divides software into different layers, where each layer is responsible for a specific part of the system's functionality. This division facilitates maintenance and scalability, as each layer can be modified without affecting the others. Typical layers include (MAISKE et al., 2018):

• Data Layer: The lowest layer, responsible for storing and managing data, including tables, stored procedures, and functions. It is usually represented by the database.
• Data Access Layer (DAL): Responsible for handling all database access operations. This layer allows changes to the database to be made without impacting other parts of the system.
• Business Logic Layer (BLL): Contains all business rules and validations necessary for the application. This layer processes data before sending it to the presentation.
• Presentation Layer: Responsible for the user interface, receiving inputs and displaying the data processed by the system.

Each layer communicates only with the adjacent layer, promoting the separation of responsibilities. This approach helps to reduce the complexity of the system, allowing developers to make changes in one layer without affecting others (MAISKE et al., 2018).

Structure of an N-Tier Architecture

+-----------------------------------------------+
|    Presentation Layer                         |
+-----------------------------------------------+
|  - User Interface (UI)                        |
|  - Input validation                           |
+-----------------------------------------------+
            ^
            ¦
            v
+-----------------------------------------------+
|    Business Logic Layer (BLL)                 |
+-----------------------------------------------+
|  - Business rules                             |
|  - Data processing                            |
|  - Specific validations                       |
+-----------------------------------------------+
            ^
            ¦
            v
+-----------------------------------------------+
|    Data Access Layer (DAL)                    |
+-----------------------------------------------+
|  - Handles database interactions              |
|  - Executes SQL queries                       |
|  - Abstracts data persistence                 |
+-----------------------------------------------+
            ^
            ¦
            v
+-----------------------------------------------+
|    Data Layer (Database)                      |
+-----------------------------------------------+
|  - Database engine (SQL Server, MySQL, etc.)  |
|  - Tables, stored procedures, functions       |
|  - Stores and manages data                    |
+-----------------------------------------------+

    

Example of N-Tier Architecture in C#

To illustrate the N-Tier Architecture, let’s consider a simple example of a product management system, where we have an MVC application that displays information about products. Here’s a basic representation of the layered architecture:

// Presentation Layer
public class ProductController : Controller
{
    private readonly ProductBLL _productBLL;

    public ProductController()
    {
        _productBLL = new ProductBLL();
    }

    public ActionResult Index()
    {
        var products = _productBLL.GetAllProducts();
        return View(products);
    }

    public ActionResult Details(int id)
    {
        var product = _productBLL.GetProductById(id);
        if (product == null)
            return HttpNotFound();

        return View(product);
    }
}

// Business Logic Layer (BLL)
public class ProductBLL
{
    private readonly ProductDAL _productDAL;

    public ProductBLL()
    {
        _productDAL = new ProductDAL();
    }

    public List<Product> GetAllProducts()
    {
        return _productDAL.GetAllProducts();
    }

    public Product GetProductById(int id)
    {
        return _productDAL.GetProductById(id);
    }
}

// Data Access Layer (DAL)
public class ProductDAL
{
    private static List<Product> _products = new List<Product>
    {
        new Product { Id = 1, Name = "Laptop", Price = 3500.99M },
        new Product { Id = 2, Name = "Smartphone", Price = 2500.50M }
    };

    public List<Product> GetAllProducts()
    {
        return _products;
    }

    public Product GetProductById(int id)
    {
        return _products.FirstOrDefault(p => p.Id == id);
    }
}

// Entity representing the Data Layer (Database)
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

Characteristics of N-Tier Architecture

Although the N-Tier architecture has its advantages, such as a clear separation of responsibilities between layers, it also has some limitations. Compared to other architectural patterns, it tends to offer less agility, performance, and scalability (GEBREKIDAN, 2023).

For example, the dependency between layers can lead to strong coupling, making the maintenance and evolution of the system more difficult. Additionally, business logic can end up being spread across several layers, making it harder to understand the application flow. Other limitations include:

• Scalability: In large systems, N-Tier can make horizontal scalability difficult, as each layer can become a performance bottleneck.
• Complexity: While the separation into layers helps with organization, it can increase the complexity of the system if not managed properly.
• Testing: Unit testing can become more complicated due to the need to mock dependencies between layers.

Clean Architecture

Clean Architecture, proposed by Robert C. Martin (also known as Uncle Bob), is an approach that emphasizes the separation of concerns and independence from frameworks, libraries, and user interfaces. The main goal is to make the system flexible and easy to test. Clean Architecture is often represented in concentric layers, where each layer has a specific responsibility (MARTIN, 2017):

• Entities: Represent domain objects and contain essential business rules.
• Use Cases: Define the operations that can be performed on the system and orchestrate business logic.
• Interface Adaptor: Serves as an intermediary between business logic and external interfaces, such as APIs or user interfaces.
• Frameworks and Drivers: Include technology-specific implementations, such as databases or user interfaces, which should be kept as far away from business logic as possible.

Structure of a Clean Architecture

        +------------------------------------------------+
        |               Presentation Layer               |
        |------------------------------------------------|
        | - Controllers (API, MVC, Blazor, etc.)         |
        | - Views (HTML, Razor, UI Frameworks)           |
        | - User Input & Output                          |
        | - Calls Application Layer                      |
        | - Mapper DTOs to ViewModels                    |
        +------------------------------------------------+
                         ¦
                         ¦
                         v
        +------------------------------------------------+
        |            Application Layer (Use Cases)       |
        |------------------------------------------------|
        | - Orchestrates application logic               |
        | - Implements use cases                         |
        | - Calls Domain Layer                           |
        | - Defines application, data and external       |
        |   interfaces                                   |
        | - Using Input and Output DTOs                  |
        +------------------------------------------------+
                         ¦
                         ¦
                         v
        +------------------------------------------------+
        |             Domain Layer (Entities)            |
        |------------------------------------------------|
        | - Business entities (e.g., Product, User)      |
        | - Core business rules                          |
        | - No external dependencies                     |
        | - Independent of frameworks                    |
        +------------------------------------------------+
           ^              ^                           ^
           ¦              ¦                           ¦
           ¦              ¦                           ¦
+-------------------+   +-------------------+   +-----------------------+
| Infrastructure    |   | Database Access   |   | External Services     |
+-------------------+   +-------------------+   +-----------------------+
| - Repositories    |   | - ORM (EF Core)   |   | - Implements external |
| - Logging         |   | - SQL, NoSQL      |   |   interfaces          |
| - Implements repo |   | - Implements data |   | - Messaging, SDKs     |
|   interfaces      |   |   interfaces      |   | - APIs                |
|                   |   | - File Storage    |   |                       |
+-------------------+   +-------------------+   +-----------------------+
    

Example of Clean Architecture in C#

Continuing with the example of the product management system, here is an implementation using some patterns from Clean Architecture:

// Domain Entity
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
}

// Output DTO
public class ProductDto
{
    public int Id { get; set; }
    public string Name { get; set; }
}

// Use Cases
public interface IGetProductUseCase
{
    Task<ProductDto> ExecuteAsync(int id);
}

public class GetProductUseCase : IGetProductUseCase
{
    private readonly IProductRepository _productRepository;

    public GetProductUseCase(IProductRepository productRepository)
    {
        _productRepository = productRepository;
    }

    public async Task<ProductDto> ExecuteAsync(int id)
    {
        var product = await _productRepository.GetByIdAsync(id);
        return product is not null 
            ? new ProductDto { Id = product.Id, Name = product.Name } 
            : null;
    }
}

// Interface Adaptor (Controller)
[ApiController]
[Route("api/products")]
public class ProductController : ControllerBase
{
    private readonly IGetProductUseCase _getProductUseCase;

    public ProductController(IGetProductUseCase getProductUseCase)
    {
        _getProductUseCase = getProductUseCase;
    }

    [HttpGet("{id}")]
    public async Task<IActionResult> GetProduct(int id)
    {
        var product = await _getProductUseCase.ExecuteAsync(id);
        return product is not null ? Ok(product) : NotFound("Product not found");
    }
}

// Repository Interface
public interface IProductRepository
{
    Task<Product> GetByIdAsync(int id);
}

// Repository Implementation
public class ProductRepository : IProductRepository
{
    private readonly DbContext _context;

    public ProductRepository(DbContext context)
    {
        _context = context;
    }

    public async Task<Product> GetByIdAsync(int id)
    {
        return await _context.Products.FindAsync(id);
    }
}

Characteristics of Clean Architecture

Clean Architecture has several characteristics that differentiate it from N-Tier Architecture, including:

• Less coupling between components: This facilitates maintenance since changes in one layer do not directly affect others.
• Ease in testing business logic: It is possible to test business logic without relying on external frameworks, resulting in faster and more reliable tests.
• Flexibility for changes: Allows you to change the user interface or persistence technology without impacting the business logic, which is crucial in an agile development environment.
• Clear organization of code: The separation of responsibilities results in cleaner and easier-to-understand code, vital for teamwork and collaboration between developers.

Final Considerations

Both architectures, N-Tier and Clean Architecture, have their places in software development. The choice between them should be made based on project needs, system complexity, and team experience. N-Tier may be suitable for simple applications, where the speed of development is more important than long-term flexibility. On the other hand, Clean Architecture excels in complex systems where maintainability and testability are crucial.

When evaluating the architecture for your project, consider not only the structure and separation of responsibilities but also how the choice of architecture will impact software quality, team collaboration, and the ability to adapt to future changes.