Introdução
Vamos começar com uma provocação:
Como você pode criar algo se nem você, nem o seu cliente sabem exatamente o que será criado?
Desenvolver um sistema — seja ele qual for — é sempre uma missão complexa. E essa complexidade se aprofunda quando você ainda não compreende as engrenagens internas do negócio onde esse sistema será utilizado.
Na realidade, é mais comum do que parece encontrar clientes que, embora estejam em busca de uma solução, não têm clareza sobre o que realmente precisam. Apesar deles terem expectativas, normalmente, não possuem uma visão precisa do que desejam alcançar.
E é bom lembrar: Talvez você também não domine a problemática envolvida. Pode se tratar de um setor altamente especializado, com práticas informais, regras não escritas e decisões que só fazem sentido dentro daquele contexto específico.
Nesse cenário, o pior movimento que você pode fazer é reagir por impulso.
Evite se precipitar para parecer prestativo ou eficiente.
Pense antes de responder.
Você provavelmente vai precisar de apoio — de alguém que conheça a operação em profundidade. Alguém que possa traduzir o cotidiano da empresa em elementos compreensíveis, organizáveis, e eventualmente modeláveis.
Esse é o ponto em que muitos profissionais tropeçam: tentam resolver rápido o que exige compreensão lenta. E, sem perceber, acabam se tornando parte do problema — em vez de contribuírem para a solução.
Se você ainda acha que tudo isso é exagero, é porque ainda não enfrentou um problema de verdade.
“Precisamos de um sistema para melhorar o setor de contratos.”
Soa claro, direto. Mas não é.
É uma frase genérica, carregada de omissões e expectativas implícitas.
E o risco é alto quando se parte de premissas frágeis.
Perfeito! Dando continuidade com o mesmo tom consultivo, maduro e estratégico, agora vamos introduzir o Domain-Driven Design (DDD) como resposta natural ao cenário caótico e incerto descrito anteriormente. A ideia é mostrar que o DDD não é apenas uma técnica, mas uma postura profissional frente à complexidade real dos sistemas.
Segue a continuação:
Quando a complexidade não pode mais ser ignorada
É diante desse cenário — de incerteza, fragmentação e urgência — que surge a necessidade de um novo tipo de abordagem.
Uma abordagem que aceite o caos inicial, mas que tenha disciplina para organizar o entendimento antes de estruturar a solução.
É aqui que entra o Domain-Driven Design.
Mais do que um conjunto de padrões, DDD é uma forma de pensar o desenvolvimento a partir do domínio — ou seja, da essência do negócio.
Ao invés de começar pelo código, pela interface ou pela tecnologia, o DDD propõe outra ordem de prioridades:
Primeiro, entenda profundamente o problema que está sendo enfrentado.
Depois, estruture esse conhecimento de forma compartilhada com os especialistas do domínio.
Só então, transforme isso em uma solução coerente — tecnicamente e conceitualmente.
Parece óbvio, mas quase ninguém faz.
A maioria pula direto para o "como" — sem saber o "porquê", nem o "o quê".
Colaboração, não adivinhação
O coração do DDD está na colaboração com especialistas do negócio.
Essas pessoas — que vivem o problema todos os dias — carregam o conhecimento necessário para guiar as decisões corretas.
Mas atenção: esse conhecimento nem sempre está estruturado, e raramente está documentado.
Ele precisa ser extraído com cuidado, validado em conversas, explorado em cenários concretos.
E você, como profissional de software, não está ali para adivinhar.
Está para perguntar, ouvir, modelar, testar hipóteses — e traduzir o que foi aprendido em uma linguagem que o sistema possa entender.
Mais do que software — entendimento
Com o DDD, o sistema deixa de ser um amontoado de regras e telas, e passa a ser um reflexo fiel do entendimento que foi construído ao longo do processo.
Esse entendimento compartilhado é o ativo mais valioso do projeto.
Porque sistemas evoluem.
Mas um bom modelo — bem construído, bem nomeado, e bem fundamentado — tem o poder de resistir ao tempo.
Se quiser, posso seguir com os próximos pontos — como os conceitos de Ubiquitous Language, Bounded Context, e o papel da modelagem tática. Deseja avançar para esse trecho também?
Essa é a normalidade em projetos reais:
- O cliente acha que sabe, mas descobre o que quer só depois que vê algo funcionando e não é aquilo que ele quer.
- Ele não consegue expressar em palavras o que deseja, mas reconhece quando algo está errado. Mas só depois que você já criou.
- E pior: ele muda de ideia com base naquilo que vê — e isso é psicologicamente previsível.
O próprio Steve Jobs já dizia:
"People don’t know what they want until you show it to them."
Fonte: The Innovation Secrets of Steve Jobs, Carmine Gallo
Requisitos são descobertos — não definidos
Essa não é só uma percepção empírica. É literatura técnica consolidada.
"Requirements are not gathered, they are created through an iterative process of discovery."
— Donald Gause & Gerald Weinberg
(Exploring Requirements: Quality Before Design)
Fonte: Amazon
Ou seja: quem promete “requisitos completos” na fase inicial está vendendo uma ilusão.
Escopo Fixo + Cliente Indeciso = DESASTRE
Se você entra em um projeto desses só pelo dinheiro ou só para agradar, o fim é quase sempre o mesmo:
- A relação se desgasta;
- O sistema nunca é “o bastante”;
- E no final, quando o escopo estoura e os nervos também, alguém vai puxar o contrato, acionar advogados, e o que era para ser uma solução vira um campo de batalha.
É o que o lendário Fred Brooks alertava em 1975:
"The hardest single part of building a software system is deciding precisely what to build."
— The Mythical Man-Month
Fonte: Amazon
O Valor só Aparece Depois de Rodar
Toda essa abordagem está, inclusive, na base do Design Thinking e do Lean Startup:
- O Design Thinking começa com empatia e imersão no problema, porque o cliente não sabe formular bem o que precisa.
- O Lean Startup (Eric Ries) prega o uso de produto mínimo viável (MVP) justamente porque ninguém sabe ao certo o que vai funcionar até ver funcionando.
"Start small, learn fast, and iterate."
— The Lean Startup, Eric Ries
Fonte: theleanstartup.com
Em resumo
Não está errado em dizer que:
- É normal o cliente não saber o que quer;
- É perigoso fingir que sabe só para começar;
- E é irresponsável seguir um contrato rígido em um cenário que claramente exige adaptação.
O erro está nos que ignoram isso e seguem cegamente metodologias “bonitas” que só funcionam em slides e post-its coloridos — e esquecem que a realidade é feita de processos, decisões difíceis e negociações contínuas.
