No mundo do desenvolvimento de software, sempre buscamos práticas que nos ajudem a compor um sistema de forma mais clara e eficiente. O Domain-driven Design (DDD) é uma dessas práticas que ganhou força por promover um design orientado ao negócio, mas será que estamos aplicando seus princípios corretamente? Muitas vezes, caímos em armadilhas na tentativa de simplificar o complexo domínio de negócios com o qual lidamos. Uma dessas armadilhas é a infame prática de criar entidades ubíquas.
O Anti-pattern Entidade Ubíqua
Quando falamos de entidades ubíquas, apontamos para um anti-pattern bastante recorrente: a utilização de uma única entidade para modelar conceitos distintos, como pessoa física e pessoa jurídica, que podem assumir diferentes papéis, como fornecedor ou cliente, dentro de um domínio. Você já se deparou com uma entidade “pessoa” no seu modelo de domínio que tentava ser a solução para todos os problemas?
Essa prática usualmente surge da ideia de que podemos simplificar nosso modelo. Parece lógico pensar que, se podemos unificar conceitos sob uma mesma entidade, estamos simplificando o design. No entanto, o que acontece, na maioria das vezes, é o oposto.
As Consequências da Entidade Ubíqua
O domínio de negócios é rico em variações e detalhes. Quando tentamos generalizar demais, criando entidades ubíquas, enfrentamos problemas como alto acoplamento e baixa coesão. Essa escolha nos leva a ignorar as nuances da linguagem ubíqua, ou seja, a linguagem comum e unificada que deve permeiar todas as partes do projeto e que reflete o domínio do negócio em questão.
Você já experimentou a dor de tentar ajustar comportamentos e fluxos de trabalho que naturalmente precisariam de conceitos separados, mas foram forçados a caber dentro de uma única abstração? Por exemplo, a entidade “pessoa” acaba se tornando sobrecarregada com responsabilidades que poderiam ser melhor distribuídas entre entidades mais especializadas e alinhadas ao domínio real.
Como Evitar a Criação de Entidades Ubíquas?
A chave para evitar cair na armadilha da criação de entidades ubíquas é manter-se fiel aos princípios do DDD. Isso inclui:
- Conversar com especialistas do domínio para capturar a linguagem ubíqua de formas mais autênticas;
- Modelar o domínio de forma a refletir as distinções e regras do negócio;
- Dividir responsabilidades entre diferentes entidades e objetos de valor quando apropriado;
- Refinar continuamente o modelo através de revisões e feedbacks, reconhecendo que o domínio de negócio pode evoluir com o tempo.
Em um exemplo prático, ao invés de uma entidade ‘Pessoa’, poderíamos ter ‘Cliente’ e ‘Fornecedor’ como entidades separadas, com atributos e comportamentos específicos para cada tipo de operação no negócio. Isso permite manter a modelagem alinhada com as diferentes necessidades de cada parte do domínio.
Conclusão
A modelagem de software orientada pelo domínio de negócios é uma ferramenta poderosa. No entanto, é vital permanecer vigilante contra práticas que inadvertidamente podem comprometer a qualidade do design do nosso software, como a tentativa de simplificar o complexo através de entidades ubíquas. Através da compreensão profunda do domínio e da colaboração estreita com especialistas do negócio, podemos evitar esses anti-patterns e atingir uma modelagem que verdadeiramente serve às necessidades do negócio.
Você se identifica com esses desafios? Já encontrou maneiras únicas de resolver problemas semelhantes no seu domínio? Encorajo você a compartilhar suas experiências como parte de nossa comunidade nos grupos de estudo e mentorias que ofereço, onde se fomenta um diálogo aberto sobre as melhores práticas em DDD.
TL;DR
- Entidades ubíquas são um anti-pattern comum quando mal aplicamos o DDD, tentando unificar conceitos distintos do domínio.
- Essa prática leva a alto acoplamento, baixa coesão e desalinhamento com a linguagem ubíqua do domínio de negócios.
- Devemos nos ater aos princípios do DDD, colaborando com especialistas do domínio e revisando constantemente os modelos para evitar entidades ubíquas e refletir fielmente o negócio.
