Modelo anêmico vs. Modelo rico

Introdução

É super pertinente entender e ter um bom embasamento sobre os modelos (models) e saber a diferença entre um modelo anêmico vs. rico. Esses conceitos que separam as arquiteturas centradas em dados das arquiteturas centradas em domínio.

Não há um conceito melhor que o outro, apenas contextos em que cada um deles fazem mais sentidos.

Desenvolvi abaixo uma tabela que separa o contexto das escolhas em três grandes fatores:

Fator	Modelo anêmico	Modelo rico
Natureza do domínio	Domínio simples, CRUD, poucos comportamentos na aplicação	Domínio complexo, com muitas regras e contextos
Responsabilidade do sistema	O sistema apenas “move dados” entre Interface e Banco de dados	O sistema tende a tomar decisões de negócios, validações, estados
Camada da aplicação	Lógica concentrada na aplicação (Application Layer	Lógica concentrada no domínio (Domain Layer)

Modelo Anêmico (Anemic Domain Model)

Um modelo anêmico, como o príprio nome sugere, é aquele que as entidades apenas representam estruturas de dados (com propriedade e getters/setters), sem comportamentos.

A lógica de negócio então fica espalhada fora do domínio, geralmente em serviços ou camadas de aplicação.

Exemplo

// Entidade (modelo anêmico)
public class Pedido
{
    public int Id { get; set; }
    public decimal ValorTotal { get; set; }
    public string Status { get; set; }
}

// Serviço que contém a lógica
public class PedidoService
{
    public void CancelarPedido(Pedido pedido)
    {
        if (pedido.Status != "Pago")
            pedido.Status = "Cancelado";
    }
}

Percebe que o modelo Pedido não sabe sabe se cancelar é permitido? quem toma essa decisão no modelo anêmico é o serviço. Podemos considerar a entidade “burra” (apenas dados) e a inteligência se concentra fora do domínio.

Modelo Rico (Rich Domain Model)

No modelo rico então, as entidades encapsulam seus próprios comportamentos, ou seja, os objetos conhecem suas regras e invariantes (coisas que não mudam). Desse modo, a lógica do negócio vive dentro do domínio, matendo-o coeso e expressivo

public class Pedido
{
    public int Id { get; private set; }
    public decimal ValorTotal { get; private set; }
    public string Status { get; private set; }

    public Pedido(decimal valorTotal)
    {
        ValorTotal = valorTotal;
        Status = "Aberto";
    }

    public void Pagar()
    {
        if (Status != "Aberto")
            throw new InvalidOperationException("Pedido não pode ser pago.");

        Status = "Pago";
    }

    public void Cancelar()
    {
        if (Status == "Pago")
            throw new InvalidOperationException("Pedido já pago não pode ser cancelado.");

        Status = "Cancelado";
    }
}

Nesse exemplo Pedido sabe como se comportar, as regras de negócios fazem parte dele e não em um serviço externo

O caminho natural da maturidade de um sistema

Naturalmente quando vamos desenvolver um sistema novo (em que não há uma rígida especificação de requisitos principalmente) é comum os desenvolvedores começarem com o modelo anêmico (por simplicidade). À medida que o sistema cresce e os requisitos e fluxos de negócios ficam mais complexos, ele naturalmente evolui para um modelo rico.

Um bom indicador de transição é quando você percebe que:

• Há regras repetidas em vários services.
• Entidades mudam de estado de formas não controladas.
• Lógicas de negócio estão espalhadas e difíceis de rastrear.

Quando isso acontece, o domínio está “pedindo” para ser encapsulado, ou seja, é hora de migrar para um modelo rico.

Qual modelo escolher em cada tipo de sistema?

Modelo anêmico

• CRUD adminsitrativos (cadastros de produtos, clientes, etc.).
• Sistemas voltados a manipulação de dados e não à lógica do negócio
• Microsserviços utilitários (logs, uploads, etc.).

Modelo Rico

• Sistemas financeiros (transações, autorizações, saldos)/
• Educação (avaliações, notas, progressos)
• Saúde (diagnóstico, prescrições e prontuários)

Relação do modelo rico com DDD

Em DDD (Domain-Driven Design), é normal ver esse tema na parte de tactical design, dentro do conceito de Domain Model Pattern.