DDD é um acrônimo para Domain Driven Design. Não se trata diretamente de uma arquitetura ou uma tecnologia; mas sim uma filosofia que prega o desenvolvimento de software de maneira alinhada aos aspectos de negócio com foco na entrega de valor.
No DDD, toda a arquitetura desenhada e até mesmo os termos utilizados nas documentações e no código devem ter relação direta com os componentes de negócio, ou seja, o domínio do software.
Embora as ideias iniciais sobre desenvolvimento orientado aos domínios de negócio não sejam necessariamente novos, o conceito do DDD foi apresentado de maneira estruturada em 2005 por Eric Evans, através do livro Domain Driven Design: tackling complexity in the heart of software.
Componente central do DDD: o que é domínio?
O domínio é basicamente o problema do ponto de vista de negócio a ser resolvido, pois o domínio justifica a existência do software.
Por exemplo, podemos imaginar uma situação em que uma empresa de venda de planos de saúde precisa de um software para auxiliar no processo de gestão de seus processos e informações.
Para algumas organizações, é difícil gerenciar os fluxos de gestão de pessoas, marketing, fiscal e contábil somente por planilhas, sendo assim necessário um software para prover mais automação e controle destes processos.
Este então seria o domínio de uma aplicação a ser desenvolvida para auxiliar neste processo de gerenciamento: automação e controle de fluxos de várias áreas da empresa. Este é o problema a ser resolvido pelo software em questão.
Domínios podem ser complexos para serem resolvidos sob um único ponto de vista. Nestes casos, o domínio pode ser ainda quebrado em subdomínios com o intuito de facilitar o processo de exploração e design da aplicação.
No nosso exemplo, o domínio, automação e controle de fluxos de várias áreas da empresa é extenso, pois uma organização possui várias subáreas. Assim, dessa maneira, poderíamos derivar alguns subdomínios a partir deste domínio, como Marketing, Recursos Humanos e Financeiro, por exemplo.
Linguagem ubíqua e bounded contexts
Devido ao fato de o DDD ser totalmente voltado ao negócio, não existe espaço para a utilização de termos ambíguos para a definição das estruturas de software e nas conversas entre os domain experts (os quais são as pessoas que dominam o negócio e provavelmente irão utilizar o software) e os times de tecnologia.
Todos os times envolvidos no projeto devem utilizar os mesmos termos e nomes para se referenciarem aos componentes de negócio do projeto.
Por exemplo: não deveríamos ter parte do time chamando o contexto de Recursos Humanos de RH e outra parte chamando de People. Termos diferentes atrapalham o alinhamento entre os domain experts e os times de tecnologia, pois a visão de negócio deve ser unificada na organização.
É necessária uma coleção de termos altamente acoplados com os aspectos de negócio, termos estes padronizados e que devem ser utilizados por todos os componentes do projeto.
Este conjunto de termos unificados e que devem ser utilizados por todos os membros do projeto constitui um dos pilares do DDD, chamado de linguagem ubíqua.
Se parte do time chama o subdomínio Recursos Humanos de RH, enquanto outra parte do time chama de People, é necessário estabelecer um termo ubíquo para fazer referência a este subdomínio, termo este que deve passar a ser utilizado por todos os membros do projeto.
A escolha deste termo ubíquo deve ser feita de maneira mais alinhada possível com o negócio, mostrando a importância dos domain experts no processo de utilização do DDD.
Porém, existem situações em que até mesmo a linguagem ubíqua pode sofrer variações dentro do mesmo domínio e subdomínio.
Por exemplo: se considerarmos o subdomínio de Marketing da situação anterior, podemos ter os clientes representados antes de comprarem um plano de saúde, mas também podemos ter mesmos clientes após comprarem um plano e se tornarem de fato clientes.
Em termos de negócio, os potenciais clientes que podem adquirir o plano de saúde são chamados de leads, enquanto os clientes que compram os planos de saúde (ou seja, os antigos leads) passam a ser chamados de clientes efetivamente. Porém, tudo isso acontece dentro do mesmo subdomínio de Marketing.
Na situação anterior, podemos perceber que até mesmo a linguagem ubíqua pode encontrar fronteiras dentro de um mesmo domínio e/ou subdomínio. As fronteiras que acabam por serem definidas em decorrência da linguagem ubíqua são chamadas de bounded contexts dentro do DDD.
Utilizar o DDD para visualizar o domínio, os subdomínios e os bounded contexts pode ajudar no processo de design da arquitetura do projeto, já que estes conceitos já apresentam divisões lógicas de maneira totalmente alinhada com o negócio.
Geralmente, subdomínios e bounded contexts acabam por se tornar serviços e microserviços dentro da arquitetura proposta para a resolução do domínio.
Porém, a vantagem é a entrega de valor ao negócio, pois até mesmo o design da solução refletirá de maneira fiel o negócio a ser atacado pelo projeto de software.
Visualizar subdomínios e bounded contexts, bem como os fluxos de interação entre estas estruturas, pode ser uma tarefa muito árdua, especialmente quando tratamos de domínios muito extensos e complexos.
Por isso, existem técnicas que conciliam os times de produto, tecnologia e os domain experts para a definição destas estruturas em conjunto.
Uma das técnicas mais famosas que podem ser utilizadas para essa missão é o Event Storming. Porém, este assunto fica para um próximo artigo :)
