Não interagir com especialistas do domínio é um dos enganos cometidos quando se utiliza Domain-Driven Design (DDD). Identificá-lo e corrigi-lo o mais breve possível pode evitar retrabalho da equipe e consequentemente, não gerar impacto negativo no cronograma do projeto, afirma Daniel Whittaker, quando descreve sobre os dez erros que regularmente os desenvolvedores cometem.
Permitir que a persistência ou repositório de dados influencie no modelo.
Tacticz/as/a/al patterns - Considerar as bases do negócio, simplificar modelos e isolá-los das preocupações com infraestrutura, como por exemplo: o repositório de dados. Iniciar com a modelagem de dados ao invés de, primeiramente, falar com especialistas do domínio pode criar um código baseado no modelo relacional ao invés de construir um modelo do domínio, o qual realmente refletirá as características do negócio. Ainda neste assunto, Stefan Tilkov alertou sobre o uso de um modelo dados canônico dentro de uma empresa, aonde os atributos opcionais e comportamentos atípicos poderiam trazer problemas na composição do modelo.
Não se envolver com os especialistas do domínio.
Falar com especialistas do negócio para obter a compreensão do domínio do problema a partir de suas perspectivas faz parte do núcleo do DDD. O Behaviour-Driven Development (BDD) enfatiza a realização de conversas com os especialistas do domínio, criando exemplos de comportamento. Além disso, Konstantin Kudryashov falou sobre a utilização das práticas do BDD e DDD em conjunto.
Ignorar a linguagem dos especialistas do domínio.
Criar uma linguagem ubíqua compartilhada com os especialistas do domínio é também uma prática presente no núcleo do DDD. Esta linguagem de comum entendimento deve ser utilizada em todas as discussões e além disso, aplicada diretamente no código, por meio de nomes de classes e métodos.
Não identificar a fronteira e a limitação dos contextos.
Uma abordagem comum para resolver problemas complexos é dividi-los em partes menores. Sendo assim, ao estabelecer a limitação dos contextos (Bounded Contexts) é possível trabalhar uma parte coesa e de menor complexidade em relação ao domínio completo ao invés de trabalhar com o todo. Esta estratégia também é conceito chave em microservices, conforme mencionado por Eric Evans em seu keynote neste ano, na conferência: DDD Exchange.
Usar um modelo de domínio anêmico.
Este é um sinal comum de que a equipe não está fazendo DDD e muitas vezes um sintoma de uma falha no processo de modelagem. A princípio um modelo de domínio anêmico muitas vezes parece um modelo de domínio real, com nomes corretos etc. Contudo, nota-se que nas classes está faltando boa parte do comportamento necessário, ao invés de apresentar as devidas operações, somente existem classes contendo métodos getters e setters para as propriedades.
Os cinco erros restantes que Whittaker identificou são:
Manter a limitação dos contextos (Bounded Contexts) apesar de obter-se um melhor entendimento a respeito do domínio. Uma vez que o processo de descoberta do domínio evolui constantemente, torna-se necessário garantir que os demais artefatos do projeto serão compatibilizados com ele.
- Assumir que toda lógica é a lógica do domínio;
- Fazer uso excessivo de testes de integração;
- Tratar aspectos de segurança como parte do domínio (a menos que se esteja trabalhando em um domínio de segurança);
- Concentrar-se na infraestrutura.
O último engano mencionado por Whittaker é não estar atento ao Event Storming, um processo de design com foco em eventos criado por Alberto Brandolini. Ao reunir os principais envolvidos em uma sala com espaço de modelagem abrangente e utilizar adesivos para representar os eventos do domínio, Brandolini afirma que eles podem em horas, produzir um modelo muito bom sobre o domínio do problema.