Introdução
E como quase ninguém entende o que isso realmente significa ...
Durante um projeto real, fui contratado para resolver uma série de problemas administrativos em uma instituição no exterior. Não havia um sistema eficaz. Os processos eram manuais, fragmentados, com sobrecarga de papel e redundâncias. O pedido era simples: "Fazer um Sistema". Mas qualquer um com um mínimo de experiência sabe que esse é sempre o pedido mais perigoso.
Ao contrário do que fazem muitos desenvolvedores decidi entender o que estava acontecendo de verdade.
Primeira Etapa: Viver o Processo
Passei por cada setor da instituição. Observei as rotinas. Participei das atividades. Fiz entrevistas informais. E, mais importante ainda: li o manual interno — aquele documento que tenta capturar o conhecimento tácito da instituição.
Comecei a perceber algumas incoerências, sobreposições, ruídos na comunicação. E também comecei a entender o "Vocabulário do Lugar". Cada setor tinha seus termos, seus ajustes legitimados, suas exceções que nunca estavam escritas em lugar nenhum, mas que todo mundo sabia que existiam.
Segunda etapa: Construir com Lucidez
Só depois dessa imersão de "Viver o Processo" é que comecei a modelar. Primeiro mentalmente, depois em fluxogramas, depois no código. O sistema que criei não era um monumento técnico. Era uma ferramenta. Um reflexo fiel da lógica administrativa que, até então, só existia na cabeça dos funcionários.
No final, acabei conhecendo muito mais da instituição do que muitos dos funcionários, pois não conhecia somente o sistema que desenvolvi mas todo o funcionamento de todos os processos da instituição. Mas isso já faz muito tempo e agora deram um nome:
Isso era o tal do Domain-Driven Design. Eu só não sabia que tinha esse nome. Alias, não tinha.
Então, o que é o Primeiro "D" do DDD?
DDD significa "Domain-Driven Design", ou "Projeto guiado pelo Domínio". Mas você já se perguntou: o que é, de fato, esse tal de Domínio?
É o conjunto de rotinas, regras, exceções, protocolos, vocabulário e cultura que regem aquele universo. Está nas conversas de corredor, no conhecimento tácito, nas planilhas improvisadas como soluções para procedimentos, no manual que ninguém segue.
Se você não viveu isso ainda, incentivo você a viver para entender claramente o que é o "Domínio". Pois, se você não entender o domínio, e estiver projetando achando que está usando "DDD", sinto informar que seu domínio é apenas uma suposição, talvez bem formatada.
A verdade Incômoda
Antes do DDD ser batizado como metodologia, profissionais sérios já o praticavam na vida real. Profissionais que já construíram sistemas respeitando o processo, ouvindo o cliente, modelando com base no que funciona ... já fazíamos DDD. Não por modismo. Mas por responsabilidade. E é por isso que o primeiro "D" é tão importante:
Domínio não se impõe. Se descobre.
E se você não está disposto a fazer isso, então você pode estar dirigindo qualquer coisa. Menos o domínio.
