Separação de Responsabilidades na Prática: Comparação entre N-Tier Architecture e Clean Architecture

Introdução

Neste artigo, vamos explorar duas abordagens populares na separação de responsabilidades: N-Tier Architecture e Clean Architecture. Ao longo do texto, discutiremos as características, vantagens, desvantagens e exemplos práticos de cada abordagem, para que você possa tomar decisões informadas na arquitetura de suas aplicações.

N-Tier Architecture?

A N-Tier Architecture, também conhecida como arquitetura em camadas, é uma abordagem que divide o software em diferentes camadas, onde cada camada é responsável por uma parte específica da funcionalidade do sistema. Essa divisão facilita a manutenção e a escalabilidade, pois cada camada pode ser modificada sem afetar as demais. As camadas típicas incluem (MAISKE et al., 2018):

• Camada de Dados: A camada mais inferior, responsável pelo armazenamento e gerenciamento dos dados, incluindo tabelas, procedimentos armazenados e funções. Normalmente, é representada pelo banco de dados.
• Camada de Acesso a Dados (DAL): Responsável por lidar com todas as operações de acesso ao banco de dados. Essa camada permite que mudanças no banco de dados sejam feitas sem impactar as demais partes do sistema.
• Camada de Lógica de Negócio (BLL): Contém todas as regras de negócio e validações necessárias para a aplicação. Essa camada processa os dados antes de enviá-los para a apresentação.
• Camada de Apresentação: Responsável pela interface do usuário, recebendo entradas e exibindo os dados processados pelo sistema.

Cada camada se comunica apenas com a camada adjacente, promovendo a separação de responsabilidades. Essa abordagem ajuda a reduzir a complexidade do sistema, permitindo que os desenvolvedores façam alterações em uma camada sem afetar as demais (MAISKE et al., 2018).

Estrutura de um 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                    |
+-----------------------------------------------+

    

Exemplo de N-Tier Architecture em C#

Para ilustrar a N-Tier Architecture, consideremos um exemplo simples de um sistema de gerenciamento de produtos, onde temos uma aplicação MVC que exibe informações sobre produtos. Aqui está uma representação básica da arquitetura em camadas:

// Camada de Apresentação (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);
    }
}

// Camada de Lógica de Negócio (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);
    }
}

// Camada de Acesso a Dados (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);
    }
}

// Entidade representando o manuseio da Camada de Dados (Data Layer - Database)
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

Características da N-Tier Architecture

Embora a arquitetura N-tier tenha suas vantagens, como a separação clara de responsabilidades entre camadas, ela também apresenta algumas limitações. Comparada a outros padrões de arquitetura, tende a oferecer menor agilidade, desempenho e escalabilidade (GEBREKIDAN, 2023).

Por exemplo, a dependência entre as camadas pode levar a um acoplamento forte, tornando a manutenção e a evolução do sistema mais difíceis. Além disso, a lógica de negócios pode acabar sendo espalhada por várias camadas, dificultando a compreensão do fluxo do aplicativo. Outras limitações incluem:

• Escalabilidade: Em sistemas grandes, a N-Tier pode dificultar a escalabilidade horizontal, pois cada camada pode se tornar um gargalo de desempenho.
• Complexidade: Embora a separação em camadas ajude na organização, pode aumentar a complexidade do sistema se não for gerenciada adequadamente.
• Testes: Os testes de unidade podem se tornar mais complicados devido à necessidade de mockar dependências entre as camadas.

Clean Architecture

A Clean Architecture, proposta por Robert C. Martin (também conhecido como Uncle Bob), é uma abordagem que enfatiza a separação de preocupações e a independência de frameworks, bibliotecas e interfaces de usuário. O objetivo principal é tornar o sistema flexível e fácil de testar. A Clean Architecture é frequentemente representada em camadas concêntricas, onde cada camada tem uma responsabilidade específica (MARTIN, 2017):

• Entidades: Representam os objetos de domínio e contêm as regras de negócio essenciais.
• Casos de Uso: Definem as operações que podem ser realizadas no sistema e orquestram a lógica de negócios.
• Interface de Adaptação: Serve como intermediária entre a lógica de negócios e as interfaces externas, como APIs ou interfaces de usuário.
• Frameworks e Drivers: Incluem implementações específicas de tecnologia, como bancos de dados ou interfaces de usuário, que devem ser mantidas o mais longe possível da lógica de negócios.

Estrutura de um 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    |   |                       |
+-------------------+   +-------------------+   +-----------------------+
    

Exemplo de Clean Architecture em C#

Continuando com o exemplo do sistema de gerenciamento de produtos, aqui está uma implementação usando alguns padrões da Clean Architecture:

// Entidade de Domínio
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
}

// DTO para saída
public class ProductDto
{
    public int Id { get; set; }
    public string Name { get; set; }
}

// Casos de Uso
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 de Adaptação (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("Produto não encontrado");
    }
}

// Interface do Repositório
public interface IProductRepository
{
    Task<Product> GetByIdAsync(int id);
}

// Implementação do Repositório
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);
    }
}

Características da Clean Architecture

A Clean Architecture apresenta diversas características que a diferenciam da N-Tier Architecture, incluindo:

• Menor acoplamento entre componentes: Isso facilita a manutenção, pois mudanças em uma camada não afetam diretamente as outras.
• Facilidade em testar a lógica de negócios: É possível testar a lógica de negócios sem depender de frameworks externos, o que resulta em testes mais rápidos e confiáveis.
• Flexibilidade para mudanças: Permite que você mude a interface do usuário ou a tecnologia de persistência sem impactar a lógica de negócios, o que é crucial em um ambiente de desenvolvimento ágil.
• Organização clara do código: A separação de responsabilidades resulta em um código mais limpo e fácil de entender, o que é vital para o trabalho em equipe e a colaboração entre desenvolvedores.

Considerações Finais

Ambas as arquiteturas, N-Tier e Clean Architecture, têm seus lugares no desenvolvimento de software. A escolha entre elas deve ser feita com base nas necessidades do projeto, na complexidade do sistema e na experiência da equipe. A N-Tier pode ser adequada para aplicações simples, onde a velocidade de desenvolvimento é mais importante do que a flexibilidade a longo prazo. Por outro lado, a Clean Architecture se destaca em sistemas complexos onde a manutenibilidade e a testabilidade são cruciais.

Ao avaliar a arquitetura para o seu projeto, considere não apenas a estrutura e a separação de responsabilidades, mas também como a escolha da arquitetura impactará a qualidade do software, a colaboração da equipe e a capacidade de adaptação a mudanças futuras.