Domain-driven design (DDD) não é tema novo (Eric Evans formalizou o conceito há mais de uma década). Entretanto, é curioso como, até hoje, os conceitos básicos sobre o assunto despertam interesse, principalmente em comunidades .NET. Ainda mais curioso é como esses mesmos conceitos são erroneamente interpretados.

A fundação de DDD está no conceito de linguagem onipresente (ubiquitous language, no original). Não está em determinar o que é uma entidade, objeto de valor, agregado, serviço ou repositório.

A impressão que temos é que quem começa a estudar DDD, lê as primeiras páginas do livro do Evans, ou do livro do Vernon, e pensa ter “captado a ideia” de ter especialistas do domínio e especialistas de tecnologia falando a mesma língua. Então, pula direto para as páginas que descrevem os padrões.

É comum falarmos com pessoas de TI que pensam que basta fazer com que o nome das classes e das propriedades, escritas por programadores, estejam de acordo com o vocabulário dos especialistas de domínio. Entretanto, essa é uma simplificação grosseira.

Para entender a importância da linguagem onipresente, comecemos pela “entidade” listada abaixo:

public class Employee
{
  public string Id { get; set; }
  public string Name { get; set; }
  public string Cpf { get; set; }
  public decimal Salary { get; set; }
}

Eis aqui um bom exemplo de implementação anêmica! Mas, antes de continuar lendo, tente imaginar o porquê.

Em nossas consultorias, quando usamos esse exemplo, ouvimos sugestões de que esta classe carece de comportamentos (O que está certo!). Entretanto, quando questionamos quais seriam os tais “comportamentos”, constatamos que as pessoas estão repetindo argumentos genéricos (de gente que também não “pegou” a ideia) e não tem condições de identificar o que há de errado!

Uma das argumentações mais frequentes é de os “setters” das propriedades deveriam estar privados. No lugar deles, deveríamos ter métodos “DefinirXXX” que implementariam validações. Concordemos, entretanto, que essa ideia não faz sentido, pois o propósito dos “setters” é, exatamente, definir valores para as propriedades e não haveria problema algum do código para validação estar implementado neles.

[tweet]Os métodos de uma entidade deveriam explicitar as motivações para suas mudanças de estado. [/tweet] Além disso, deve haver pelo menos um construtor capaz de instanciar a entidade colocando-a, desde o início, em estado válido.

Não é incomum encontrarmos implementações de propriedades que verificam, por exemplo, se o valor que se está tentando atribuir é diferente de nulo. Entretanto, nulo é o valor default do tipo e é assumido quando a classe é instanciada.

Vejamos outro exemplo de classe anêmica e sem valor para o domínio.

public class Customer 
{
  public string Name { get; private set; }

  public string Email { get; private set; }

  public DateTime BirthDate { get; private set; }

  public Customer(Guid id, string name, string email, DateTime birthDate) 
  {
    Id = id;
    Name = name;
    Email = email;
    BirthDate = birthDate;
  } 
}

Na classe acima temos um “record” comum para uma implementação funcional. Mas, não temos uma entidade. A ideia até faria sentido em uma linguagem puramente funcional onde a “entidade” fica espalhada conceitualmente em diversas funções que definem comportamento, mas, em C#, não tem sentido algum.

Vamos a uma segunda tentativa com nossa classe Employee:

public class Employee
{
  public string Id { get; private set; }
  public string Name { get; private set; }
  public string Cpf { get; private set; }
  public decimal Salary { get; private set; }

  public Employee(string name, string cpf) 
  {
   //..
  }

  public void RaiseSalary(decimal amount)
  {
    //..
  }
}

Dessa vez, a entidade é potencialmente menos anêmica. Afinal, estão claras as motivações que levam a mudança de valor das propriedades. Perceba como, inclusive, fica mais claro o valor da escrita de testes. Afinal, em uma classe anêmica (só com propriedades), os testes validariam a capacidade do C# de aceitar mudanças de valor (o que a Microsoft, com certeza, já testou e garante).

O problema do código acima está no método “dar aumento”. Por quê? Por essa não ser a forma como especialistas de domínio descrevem essa operação (fale com alguém de RH e irá ouvir expressões como “movimentação salarial”, “acordo coletivo” e “dissídio”. Mas, não ouvirá nada sobre “dar aumento”). Ou seja, o código não está fiel a linguagem onipresente.

Para pensar…

Identificar e implementar a linguagem onipresente não serve apenas para definir nome de classes ou de propriedades. A linguagem onipresente deve se revelar, principalmente, nas motivações para as mudanças de estado de nossas entidades de forma explícita.

Entender, de verdade, a linguagem onipresente é muito mais importante do que aprender os padrões. Sozinhos, o valor deles é nulo.

Preocupe-se, primeiro, em aprender o mais importante. Dedique tempo e esforço para entender bem isso. Depois, pode até fazer sentido pensar em associar DDD com conceitos mais técnicos geralmente entendidos como mais avançados como CQRS, sagas, event sourcing e tudo mais (complexidade de solução técnica, mal justificada, é só custo!).