Domain, model, entity: vamos falar de arquitetura

Este é um post para o programador ou analista de sistemas que busca algo além do simplesmente escrever códigos. É para aquele que se preocupa com os detalhes mais importantes do software, que prefere investir em planejamento do que ter que refazer as coisas.

Nos projetos mais complexos o desafio de desenhar soluções de sistemas tecnológicos fica por conta do arquiteto ou do engenheiro de software. O programador é o responsável pela execução. Aquele loop padrão: codificar, testar e commitar. No entanto, muitas vezes esse cara é único na empresa ou a função dele é única no departamento, ou seja, o programador é responsável por TUDO e nesses casos muitas vezes o sistemas não tem uma arquitetura definida.

Por outro lado, olhando agora para o software e não para o sistema, a arquitetura deste é definida pela escolha do framework. Flask, Spring Boot, Symfony, só para citar alguns. Geralmente o famigerado MVC(Model, View e Controller) é a primeira opção. Seguindo as documentações muitas vezes se consegue algo com qualidade no mínimo razoável. O problema é que em muitos casos o entendimento dessa arquitetura é negligenciado. As responsabilidades são confundidas e a benefícios dessa ou outra arquitetura não é atingido: baixo acoplamento, testabilidade, manutenibilidade, coesão, entre outras.

O objetivo deste post não é explicar a arquitetura MVC, mas simplesmente entender o M do MVC e encontrá-lo dentro de outras arquiteturas. Apenas decorar definições leva a uma zona de conforto que impede o analista/programador de extrair detalhes de negócios em conversas com não programadores, obter informações importantes e definir corretamente quais são as entidades da aplicação. Entender o domínio do negócio é essencial para uma modelagem apropriada.

Se você leu até aqui já deve ter percebido que quando falo de Model, de Domain e de Entidade, parece que estou falando da mesma coisa. São conceitos relacionados a modelos arquiteturais que na verdade tratam do mesmo assunto(ou objeto).

Model: em MVC a camada Model representa os dados e fornece as regras de acesso aos mesmos. Além disso é camada responsável pela lógica e regras de negócio.

Domain: em uma arquitetura hexagonal a camada chamada de domain ou de domínio trata simplesmente da lógica de negócio. Essa camada não provê o acesso aos dados, apenas as regras.

Entities: em Clean Architecture é a camada responsável pelas regras de negócio. Assim como na Hexagonal Architecture não faz o acesso aos dados.

Para se aprofundar no assunto, recomendo dois excelentes livros, seguem os links abaixo, em português e inglês.

Clean Architecture (Uncle Bob)

Domain Driven Design (Eric Evans)