C# - Modelo Anêmico x Modelo Rico

Hoje vamos recordar o que é o modelo anêmico e o que é o modelo rico apresentando as diferenças e o uso de cada modelo.

Definir o modelo de domínio é uma tarefa corriqueira e que é feita quase que automaticamente definindo a classe de domínio e apenas as propriedades que expressam os atributos do objeto sendo modelado. Isso é um padrão definido como modelo anêmico.

Assim um modelo de domínio anêmico é um modelo sem comportamentos onde temos diversas propriedades com get e set definidas sem lógica alguma e onde o cliente(quem vai usar a classe) da classe tem controle sobre como instanciar e modificar a classe.

Exemplo de modelo anêmico:

    public class Cliente
    {
        public int Id{ get; set; }
        public string Nome { get; set; }
        public string Endereco { get; set; }
    }

Nesses modelos, o cliente precisa interpretar o objetivo e o uso da classe e a lógica é enviada para outras classes, denominadas serviços da classe de domínio. Com a lógica em outra classe, não há nada que ajude o cliente a navegar ou usar a classe de modelo.

Essa abordagem acarreta muitos problemas e desvantagens de design como :

Nota: Coesão é o nível interno de integradidade de uma classe. Uma classe com alta coesão possui responsabilidades bem definidas e são difíceis de serem desmembradas em outras classes;

Em contrapartida ao modelo anêmico temos o modelo de domínio rico que inclui nas classes de domínio os dados e o comportamento e onde a lógica de domínio faz parte das entidades.

Essa lógica orienta e controla como a entidade é instanciada, validada e operada, impedindo que o cliente tenha entidades com um estado inconsistente.

Exemplo de modelo rico:

    public class Cliente
    {
        public int Id{ get; private set; }
        public string Nome { get; private set; }
        public string Endereco { get; private set; }     
        public Cliente(int id, string nome, string endereco)
        {
            if (id < 0)
                throw new InvalidOperationException();
            if (string.IsNullOrEmpty(nome) || string.IsNullOrEmpty(endereco))
                throw new InvalidOperationException();
            Id = id;
            Nome = nome:
            Endereco = endereco;
        }
    }

Obs: Para deixar o artigo mais simples não estou entrando nos conceitos de Entity, Value Object, Aggregates e Roots do DDD.

Aqui o cliente da classe somente pode atribuir valores para as propriedades via construtor e os valores estão sendo validados(de forma bem ingênua) o que garante mais consistência ao objeto gerado.

Como evitar o modelo anêmico

Existe uma longa lista de práticas recomendadas que você pode usar para evitar um Modelo de Domínio Anêmico, sendo que isso também depende da complexidade da solução e de quão purista você deseja ser quando for enriquecer seu modelo. (no nosso exemplo adotamos uma abordagem bem simples)

O objetivo deste artigo não é apresentar um estudo completo ou uma lista exaustiva das melhores práticas, mas aqui estão algumas dicas e sugestões para você começar:

Essas diretrizes são bem genéricas mas são simples de seguirem e fáceis de serem implementadas.

O modelo anêmico foi classificado por Martin Fowler como um anti-pattern, mas mesmo assim continua a ser usado e ensinado e talvez isso esteja ocorrendo pelos seguintes motivos:

1- A programação procedural é mais fácil que a programação orientada a objetos.

Modelos de domínio anêmicos têm a lógica de domínio em algumas outras classes de serviço. Quando você trás o comportamento do seu domínio para as classes de serviços do domínio, basicamente está pegando um objeto, operando com ele e seus dados e devolvendo-o ao cliente. Acontece que isso não é POO, é programação procedural.

2- Soluções com baixos requisitos lógicos.

Para algumas soluções sem lógica de domínio associada, principalmente a operações CRUD, um Modelo de Domínio Anêmico usando uma arquitetura MVC pode ser suficiente, e você vai encontrar dezenas de artigos mostrando e usando essa solução.

Pense bem nisso quando for definir o seu modelo de domínio.

Em outro artigo veremos como tratar exceções neste contexto.

"Dando graças ao Pai que nos fez idôneos para participar da herança dos santos na luz;
O qual nos tirou da potestade das trevas, e nos transportou para o reino do Filho do seu amor;"
Colossenses 1:12,13

Referências:

José Carlos Macoratti