No desenvolvimento de software, compreender o domínio de negócio é essencial para criar sistemas eficazes que atendam às necessidades dos usuários. O Domain-Driven Design (DDD) oferece uma abordagem poderosa para alcançar essa compreensão profunda, destacando a importância de modelar o domínio de forma clara e precisa. Neste artigo, exploraremos o conceito de Domínio Destilado, uma interpretação simplificada do DDD que visa tornar mais acessíveis os princípios e práticas fundamentais do design de domínio. Veremos como o Domínio Destilado pode ser aplicado de forma prática para criar sistemas de software que se alinhem melhor com as necessidades reais do negócio.
Aqui no blog, além do Domínio Destilado, temos uma grande quantidade de artigos sobre DDD, mas gostaria de destacar alguns que não são obrigatórios para a leitura desse, mas podem dar maior contexto:
Sumário
1 – O Domínio destilado
Ouço muita coisa por aí no mercado de desenvolvedores que tentam sintetizar o Domain Driven Design em uma frase. Algumas coisas são bobagens irrelevantes e outras são conclusões que não vêm diretamente da fonte. É claro que devemos usar conclusões de terceiros, mas ignorar a fonte pode ser um vício que bagunça a sua intenção original.
O que é o Domínio no DDD
Para Eric Evans em seu livro clássico o domínio tem uma estrutura bem definida. O diagrama a seguir mostra essa visão, com elementos bastante específicos como núcleo segregado ou núcleo abstrato. Dificilmente vemos isso em explicações dos gurus da moda de hoje (2024). Isso talvez seja porque nem todos os conceitos do Evans eram realmente relevantes, mas talvez valham ser compreendidos.
Minha interpretação sobre o domínio
Agora, a partir dos preceitos do autor eu entendo e pondero. Mas tento me colocar na posição dele no momento em que ele escreveu ou pensou o que disse. Por isso, para facilitar meu entendimento reconstruí a visão dele numa forma que me cria mais significado no momento que vivo. Esse segundo diagrama não vem do autor e, portanto, tem elementos novos. Ao longo do artigo falarei sobre esses diagramas e como podemos entender os domínios.
O que é o domínio
Vamos lá, domínio pode ser conceituado como a esfera de conhecimento e expertise que a aplicação visa abordar e resolver. Ele representa as regras de negócio, conceitos, processos e lógicas essenciais para a aplicação. Ele reflete o próprio negócio e abrange todos os seus aspectos. Os sistemas construídos são baseados em um domínio. Por exemplo, um hospital do coração lida essencialmente com esse tema. Questões específicas de Propriedas Intelectual pode não fazer sentido para esse tipo de empresa.
Declaração de visão do domínio
O autor do conceito, Eric Evans, considera que deva existir um documento de referência chamado Declaração de visão do domínio. Esse documento é a essência de todo o trabalho quando se tem o DDD como referência. Ele destaca o propósito, valores, público alvo, e tudo o que norteia o domínio. Além disso ele deve ser alinhado com outros elementos estratégicos da organização como Plano Estratégico, Missão, Visão, Valores, entre outros.
Escolhendo o núcleo destacado
Nesse sentido o domínio pode ter contornos que são mais importantes do que outros. Eles devem ser destacados, seja apenas separando lógicamente ou em módulos físicos. Isso traz maior significado para quem tem que lidar com ele. Podemos entender que essa e a parte mais importante do domínio.
Domínio destilado e modelo profundo
O Eric fala muito do processo de destilação. Acho essa tradução um pouco ruim porque destilar, de modo geral em português (pt-br) é ligado ao alcool. Mas o autor quer falar sobre a filtragem das impurezas até que o código fique límpido. Trata-se de um processo de contínuas refatorações até que se encontre esse estado ótimo.
Quando falamos nos níveis mais microscópicos do código, a limpeza está em garantir que o significado de uma entidade reflita fielmente o que ele é para o negócio. Mas isso também é verdade para os níveis mais altos. Portanto o domínio e seus sub-domínios genéricos, núcleos e mecanismos devem também refletir o negócio mantendo tudo num estado de ótimo, criando o tal do Domínio Destilado. (Ótimo é quando o pior cenário e o melhor cenários são os mesmos.)
2 – O domínio por dentro
Sub-domínios genéricos terceirizados
Esse é legal: os sub-domínios genéricos. Alguns domínios da organização são relevantes mas não devem ser diferenciais competitivos. Por exemplo, uma empresa de engenharia não precisa ter, necessariamente, um sistema de contas a pagar como diferencial. Mas um escritório de contabilidade que vende serviços nesse sentido sim.
Há um framework administrativo chamado RGT (Run-Grow-Transform) que considera que iniciativas, projetos, portfólios, tarefas, etc. devem ser classificados em um desses 3 tipos. Run the Business, tarefas mínimas necessarias para a empresa manter as luzes acesas. Grow the Business, tarefas que darão alguma nova capacidade à organização, mas sem disrupção ou propósito de grande escala. Por fim temos o Transform the Business que lida com grandes capacidades estratégicas e com propósito de grande impacto organizacional. O Run, de modo geral, pode estar alocado como um sub-domínio genérico, terceirizável e pouco gerador de diferencial. O Grow é algo a decidir, e o Transform é um grande candidato a estar no núcleo destacado ou pelo menos no Núcleo Segregado.
Núcleo Segregado
Ao observar o núcleo destacado é possível notar algumas partes que poderiam ser separadas por não parecer estar no local certo. Em alguns casos separar em sub-domínios genéricos pode não ser viável então o núcleo segregado se torna uma opção. Ele pode ser separado fisicamente ou não (digo, separando em mais de um projeto ou componente).
Para o autor, o bom núcleo segregado pode ser fruto de uma estrutura abstrata de núcleos segregados, por um estrutura chamado de Núcleo Abstrato. Porém entendo que um núcleo segregado é, na verdade, um candidato a se tornar um sob-domínio genérico.
Mecanismo coeso
É importante entender que os domínios têm uma função de esclarecer o que são os grandes conceitos/negócios da organização e como eles se dispõe. Os mecanismos coesos dizem respeito a estruturas gerais que engenham coisas. Isso lida especificamente com o ‘Como’ das coisas.
Esse é um dos conceitos do DDD que só vi no livro. Simplesmente ninguém se interessa por ele. Mas para o autor, mesmo nos níveis mais altos nem tudo é ‘O que’. Ele cita como exemplo no livro um mecanismo para lidar com hierarquia relacionado com as Interfaces Reveladoras de Intenções. Particularmente compreendi, mas ainda assim eu preferiria alocar esse conceito como algo de um domínio em específico.
Estilo declarativo
Na época em que o livro foi escrito o XML imperava. Me lembro quando a microsoft lançou o .NET 3 (em 2006) com os frameworks WPF (Windows Presentation Foundation), WCF (Windows Communication Foundation), WWF (Windows Workflow Foundation) e um específico para credenciais. Esses Foundations tinham grandes XML’s onde o programador configurava grande parte da aplicação ou definia posições de layout, ou ordem de tarefas em um workflow. Era interessante até certo ponto, mas engessava a arquitetura por outro.
Lembrei disso por que o Eric defende que o estilo declarativo de programação é algo que dá maior transparência. Ele flerta com a ideia de DLS (Domain Specific Languages) como linguagens para química, para seguradoras, etc. Para ele os bons domínios podem ser expressados de modo mais declarativo.
3 – Considerações de uso
Sub-domínios genéricos versus Mecanismos coesos
Ambas as estruturas existem como especializações do domínio, mas a primeira focada em conceituar e a segunda focada em explicar o funcionamento. Como já comentei, entendo como mais relevante observar apenas os sub-domínios e alocar mecanismos como estruturas internas de domínios, garantindo que as camadas mais altas (perto da estratégia da organização) estejam focadas “no que” e não no “como”.
O domínio e a estratégia se confundem
Algo que fica claro em todos essa questão é que não estamos falando específicamente de código, mas sim de como organizar uma empresa. Parece estranho, haja visto que muitas empresas são organizadas por administradores, gestores de RH ou outros que nada entendem de TI. Veja que quando eles fezem isso, eles definem a arquitetura empresarial que fatalmente afetará os softwares desenvolvidos.
Note a relevancia do documento de visão do domínio que tem por objetivo consolidar a visão estratégica da organização com a do software. De maneira geral nunca vi ninguém fazendo esse documento, mas sim fazendo PETI – Plano Diretor de TI ou PDTI – Plano Estratégico de TI, que podem de certo modo suportar tais conceitos.
Domínio destilado e o Corpo estranho
O conceito de corpo estranho não foi criado pelo autor mas sim por mim. Se consideramos que há o domínio e que os principais elementos que estruturam a organização que são refletidos no software estão abaixo dele, então o que poderia não estar no domínio? Teoricamente tudo está nele. Mas algumas empresas podem não ter um cuidado com a construção, manutenção e descarte de alguns negócios que ela mesma constrói. Isso faz com que alguns negócios existam mas que não façam sentido para ela. Chamo isso de corpo estranho.
Esses tipos de domínio devem ser incorporados efetivamente ao domínio, logo deve ser partinente ao negócio, caso contrário deve ser eliminado pela empresa. Enquanto isso não ocorre, ele mantém esse estado de corpo estranho.
Estrutura externa
Na época em que o livro foi escrito a grande arquitetura distribuida que se falava era o WebService com WSDL e SOAP. Atualmenta há uma enormidade de aplicações disponíveis que podemos nos conectar para fazer nossas aplicações, sejam por APIs REST, WebSockets, etc. Talvez por isso o autor não destacou isso, mas entendo que alguns elementos externos são fundamentais, sendo domínio que a empresa enxerga, embora estejam fora da fronteira da organização.
Conclusão de Domínio destilado
O artigo Domínio Destilado apresenta uma interpretação prática e simplificada do Domain-Driven Design (DDD), abordando tópicos como: o que é domínio, declaração de visão do domínio, sub-domínios genéricos, mecanismos coesos etc. Ele destaca a importância de entender profundamente o domínio de negócio e de aplicar esses conceitos de forma prática no desenvolvimento de software, visando criar sistemas mais alinhados com as necessidades reais da organização.
Ele atua/atuou como Dev Full Stack C# .NET / Angular / Kubernetes e afins. Ele possui certificações Microsoft MCTS (6x), MCPD em Web, ITIL v3 e CKAD (Kubernetes) . Thiago é apaixonado por tecnologia, entusiasta de TI desde a infância bem como amante de aprendizado contínuo.