Eu sei, parece contraintuitivo. A gente passa anos estudando linguagens, frameworks, padrões de arquitetura, e aí vem alguém dizer que a técnica não é o diferencial?
Calma, não é isso.
A técnica é essencial, mas ela sozinha não sustenta a vantagem competitiva de um subdomínio core. E entender isso muda completamente a forma como você se posiciona, entrega valor e evolui dentro de um produto.
O que define um subdomínio principal
Khononov, separa subdomínios em três categorias: genéricos, de suporte e principais. Nos dois primeiros, a complexidade deve ser minimizada ao máximo, são áreas que não geram diferencial de mercado e, portanto, não justificam investimento pesado em modelagem ou abstração. Compre pronto, use uma lib, delegue. O custo de sofisticar algo que não diferencia o produto é alto demais para o retorno que traz.
Já o subdomínio principal é onde a mágica acontece. É ali que o produto se diferencia da concorrência, onde o modelo de negócio ganha forma no código, onde cada decisão técnica carrega um peso estratégico real. E é justamente por isso que a vantagem competitiva desse subdomínio vai além da técnica.
Se fosse só sobre código, bastaria contratar os melhores programadores do mercado e o problema estaria resolvido. Mas não é assim que funciona, e todo mundo que já trabalhou em um produto complexo sabe disso.
A complexidade certa nasce do problema, não do código
Existe uma diferença enorme entre complexidade essencial e complexidade acidental. A essencial é inerente ao problema que estamos resolvendo, ela existe porque o negócio é complexo, porque as regras são intrincadas, porque o mercado exige. A acidental é aquela que nós mesmos criamos: over-engineering, abstrações prematuras, padrões aplicados sem contexto.
O subdomínio principal precisa abraçar a complexidade essencial. Ela é bem-vinda ali. Mas precisa ser a complexidade certa, e a complexidade certa não nasce de uma decisão técnica brilhante. Nasce do entendimento profundo do problema.
Quantas vezes você já viu um sênior entregar uma solução tecnicamente impecável que não resolvia o problema real? Ou pior, que resolvia um problema que ninguém tinha? Esse é o sintoma clássico de quem domina a ferramenta mas não entende o terreno onde está pisando.
É como um cirurgião com a melhor técnica do mundo operando o órgão errado. A execução foi perfeita, mas o resultado é desastroso.
O especialista que muda o jogo
O profissional que domina o subdomínio principal consegue algo raro: antecipar necessidades que o próprio cliente ainda não enxergou. Ele questiona requisitos que parecem óbvios. Ele não pergunta "como vou implementar isso?" antes de perguntar "por que isso precisa existir?".
Esse é o ponto de inflexão.
Quando você entende profundamente o domínio, a conversa com o time de produto muda. Você deixa de ser um receptor de tarefas e passa a ser um co-criador da solução. Não porque você aprendeu um novo framework, mas porque você entende as dores, as restrições, as oportunidades que o negócio apresenta.
Eric Evans fala sobre isso quando menciona a linguagem ubíqua. Não se trata apenas de nomear classes e métodos com termos do negócio. Trata-se de pensar com os termos do negócio. Quando você internaliza a linguagem do domínio, suas decisões técnicas passam a ser orientadas pelo problema real, e não por preferências pessoais ou tendências do momento.
Na prática, isso se traduz em perguntas que poucos fazem:
- Essa feature resolve uma dor real ou estamos apenas seguindo o roadmap no automático?
- Esse nível de sofisticação técnica se paga dentro do ciclo de vida desse subdomínio?
- Essa modelagem reflete como o negócio realmente opera ou como a gente acha que ele deveria operar?
São perguntas simples, mas que mudam drasticamente a qualidade do que é entregue.
O técnico como commodity
Pode parecer duro, mas o conhecimento técnico isolado está se tornando cada vez mais comoditizado. Isso não significa que ele não importa. Significa que ele é condição necessária, mas não suficiente.
Saber React, Node, Python, Go, qualquer stack, é o mínimo. É a barreira de entrada. O que diferencia é o que você faz com esse conhecimento quando colocado diante de um problema real de negócio.
Pense no seguinte: quantas pessoas você conhece que são excelentes tecnicamente mas não conseguem traduzir problemas de negócio em soluções? Ou que sabem tudo sobre arquitetura mas não entendem por que estão construindo aquilo?
A vantagem real está na intersecção. É quando você entende tanto do problema que a tecnologia se torna apenas a ferramenta, não o objetivo.
O impacto no dia a dia
Quando um dev domina o subdomínio principal, o impacto é visível em várias camadas:
- Na qualidade das entregas, porque as soluções resolvem o problema certo.
- Na velocidade do produto, porque se gasta menos tempo com retrabalho e features mal direcionadas.
- Na comunicação com stakeholders, porque existe um vocabulário compartilhado que elimina ruído.
- No posicionamento profissional, porque você deixa de ser a pessoa que executa e passa a ser a pessoa que direciona.
Isso muda a dinâmica do time inteiro. Um dev que entende o domínio profundamente puxa o nível da conversa para cima, desafia premissas fracas e propõe alternativas que só quem vive o problema consegue enxergar.
Como cultivar isso
Não existe atalho. Entender um domínio profundamente exige tempo, curiosidade e, principalmente, disposição para sair da zona de conforto técnica.
- Converse com quem opera o negócio.
- Pergunte o porquê das regras que parecem arbitrárias.
- Entenda a história por trás das decisões que moldaram o produto.
- Questione requisitos antes de implementá-los.
- Participe de reuniões que teoricamente "não são para devs".
- Leia sobre o mercado em que o produto está inserido.
Parece simples, e é. Mas quase ninguém faz. A maioria prefere estudar o próximo framework do que entender por que o cliente cancela o plano no terceiro mês.
O mercado não paga pelo código mais bonito. Paga pela solução que resolve o problema certo, da maneira certa, no momento certo.
E isso, definitivamente, não se aprende só lendo livro técnico.
Referências bibliográficas
KHONONOV, Vlad. Aprenda Domain-Driven Design (2022). EVANS, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software (2003).
Top comments (0)