Introdução
Quando comecei a estudar DDD, minha atenção foi quase toda para a parte tática. Queria entender como organizar o código, criar uma boa estrutura de pastas e aplicar aqueles padrões que apareciam em artigos, vídeos e repositórios no GitHub: aggregate, value object, domain event, repository, domain service, CQRS, event sourcing e por aí vai.
Na minha cabeça, aplicar DDD era muito sobre conseguir montar uma arquitetura bonita, com as responsabilidades bem separadas e nomes que pareciam fazer sentido. Enquanto isso, alguns conceitos como linguagem ubíqua, bounded context, context map... acabavam ficando em segundo plano. Eu até sabia que eles existiam, mas pareciam uma etapa mais abstrata, teórica demais, antes da parte que realmente me interessava: escrever código.
Depois de alguns projetos de exemplo, comecei a perceber um padrão. No começo tudo parecia organizado, mas conforme o domínio crescia, as decisões começavam a ficar confusas. Precisava combinar vários agregados, criava serviços de domínio para resolver regras que ainda não entendia bem, movia responsabilidades de um lado para o outro e tentava encaixar mais um padrão que parecesse resolver a situação.
O problema é que eu ainda não sabia exatamente o que queria construir. Seguia uma lista de padrões sem entender, de fato, o motivo por trás de cada um. O resultado era um software tecnicamente organizado, mas pouco conectado com a realidade do negócio.
Este artigo abre uma série de textos inspirada nas discussões do clube do livro da Tech Leads Club. O livro que estamos lendo é Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy, e a proposta aqui é usar essa leitura como ponto de partida para organizar meu entendimento e aplicar essas ideias na construção de um sistema.
Neste primeiro texto, vamos começar justamente por onde eu deveria ter começado: o DDD estratégico. Antes de falar sobre código, vamos olhar para domínio e os subdomínios usando como exemplo o domínio de Turismo.
DDD estratégico
A ideia do DDD estratégico não é começar desenhando pastas, classes ou camadas da aplicação. Antes disso, precisamos entender em que domínio estamos trabalhando, quais partes desse domínio são mais importantes para o negócio, quais problemas precisam ser resolvidos e quais conceitos fazem sentido para as pessoas que vivem aquele contexto no dia a dia.
Essa etapa ajuda a responder perguntas como:
- Qual é o problema principal que o software precisa resolver?
- Onde está o diferencial do negócio?
- Quais partes do sistema merecem mais investimento de modelagem?
- Onde um mesmo termo pode ter significados diferentes dependendo do contexto?
#### Conceitos fundamentais
O primeiro é domínio. No DDD, domínio é a área de atividade que o software precisa compreender. É o pedaço da realidade em que a empresa atua e onde o sistema precisa fazer sentido.
O segundo é subdomínio. Um subdomínio é uma parte menor e mais específica dentro desse domínio maior. Ele representa um recorte do problema de negócio.
O terceiro é o especialista de domínio. O especialista de domínio é a pessoa que conhece o problema de verdade. É quem entende as regras, as exceções, os conflitos, os termos usados na operação e o que realmente importa para o negócio. Nem sempre essa pessoa é alguém de tecnologia. Muitas vezes ela está em áreas como atendimento, operações, vendas, financeiro, produto ou gestão.
Disclaimer: como este artigo é um exercício, eu mesmo vou assumir o papel de especialista de domínio :)
O que é domínio?
Quando falamos de domínio no DDD, estamos falando da área da realidade que precisa ser entendida para que o sistema cumpra seu papel. Se estamos falando de um e-commerce, o domínio está ligado à operação de venda. Se estamos falando de uma plataforma de streaming, o domínio está ligado à distribuição e ao consumo de mídia.
No nosso caso, dizer apenas que o domínio é Turismo ainda é abstrato demais. É parecido com dizer que o domínio da Uber é transporte urbano. Não está errado, mas ainda não ajuda muito a entender o problema de verdade.
Então precisamos refinar. O nosso recorte aqui será Turismo de Experiência. A ideia é oferecer uma experiência completa, facilitando a escolha de hospedagens, guias, roteiros e experiências locais. Nosso software fica responsável por fazer o melhor match entre turistas, guias e rotas com base no perfil e nos gostos do cliente, tornando o processo da viagem algo mais simples.
Percebe que aqui já começa a aparecer uma pista importante? O sistema não quer só listar opções. Ele quer montar uma experiência personalizada na hora de escolher sua viagem. E isso ajuda a entender onde talvez esteja o diferencial do negócio.
Onde entram os subdomínios?
Sabemos qual é o domínio e já temos uma noção melhor do que queremos fazer. A próxima pergunta é: o que realmente diferencia nossa empresa? O que fazemos com maestria que pode virar vantagem competitiva?
Para responder isso, precisamos quebrar um pouco mais o problema. É aí que entram os subdomínios.
Um jeito simples de pensar é assim:
- domínio é o problema maior que a empresa quer resolver
- subdomínio é uma parte coerente desse problema
No nosso exemplo, o problema que a parte de gestão dos roteiros resolve é diferente do problema de gerenciar parceiros. O problema de reservas é diferente do problema de pagamentos. Tudo está dentro do mesmo domínio, mas não representa a mesma coisa.
Uma heurística boa aqui é olhar para conjuntos coerentes de casos de uso: se os mesmos atores, os mesmos dados e as mesmas regras aparecem juntos com frequência, existe um bom sinal de que ali temos um subdomínio separado.
Subdomínios
No nosso contexto, em que estamos desenvolvendo um software novo, a gente ainda vai descobrir onde estão esses subdomínios. Em uma empresa já estabelecida, isso costuma aparecer de forma mais natural na própria operação: atendimento, marketing, financeiro, operações e por aí vai.
Depois de mapear os subdomínios, precisamos classificá-los entre Core, Generic e Supporting.
| Tipo | O que representa | Estratégia |
|---|---|---|
| Core | Parte mais valiosa e mais ligada ao diferencial do negócio | Mais investimento, mais cuidado e modelagem mais rica |
| Generic | Coisas que quase toda empresa precisa | Comprar, integrar ou resolver da forma mais simples possível |
| Supporting | Partes importantes, mas que não são o diferencial principal | Construir de forma objetiva, sem sofisticar demais |
Quando falamos de Core, estamos nos referindo à parte principal do software, onde mora a vantagem competitiva. É onde faz sentido colocar mais energia, mais atenção e as melhores cabeças da equipe.
O Generic é aquilo que todo mundo faz. Algo que a gente até pode desenvolver, mas que muitas vezes faz mais sentido contratar ou integrar. Exemplos clássicos são gateways de pagamento, OAuth, autenticação e envio de e-mails.
Por fim, temos o Supporting, que apoia o negócio principal mas não é o centro dele. Normalmente aqui aparecem regras importantes, só que mais simples, sem exigir o mesmo nível de modelagem que o core.
Também vale um detalhe: isso não é regra absoluta. Auth e pagamentos normalmente entram como genéricos, mas, em alguns contextos, uma empresa pode escolher manter isso internamente por custo, escala, compliance ou estratégia. DDD não manda comprar tudo. DDD manda pensar.
Uma matriz simples para pensar nisso
| Aspecto | Core | Generic | Supporting |
|---|---|---|---|
| Vantagem competitiva | Sim | Não | Não |
| Complexidade | Alta | Pode ser alta, mas comum ao mercado | Baixa a média |
| Volatilidade | Alta | Geralmente baixa | Baixa a média |
| Estratégia | Investir forte | Comprar, integrar ou reaproveitar | Resolver sem sofisticar demais |
| Time | Mais experiente | Pode ser vendor ou solução pronta | Pode evoluir junto com o produto |
Os subdomínios do nosso exemplo
Se olharmos para o problema descrito até aqui, uma primeira lista de subdomínios seria algo como:
- Curadoria e match de experiências
- Gestão de ofertas
- Gestão de parceiros
- Reserva e disponibilidade
- Pagamentos
- Identidade e acesso
- Notificações
Considerando que o diferencial da nossa empresa está em montar a melhor experiência possível para cada turista, então curadoria e match de experiências provavelmente é o nosso Core Domain.
Uma classificação inicial poderia ficar assim:
| Subdomínio | Classificação | Papel no negócio |
|---|---|---|
| Curadoria e match de experiências | Core | Encontrar a melhor combinação entre perfil do turista, guia, roteiro e experiência |
| Gestão de ofertas | Supporting | Organizar roteiros, pacotes, hospedagens e eventos como opções ofertáveis ao turista |
| Gestão de parceiros | Supporting | Gerenciar guias, anfitriões e outros prestadores, com perfis, especialidades, idiomas e disponibilidade |
| Reserva e disponibilidade | Supporting | Coordenar consulta de disponibilidade, bloqueio de vagas, confirmação, cancelamento e regras de reserva |
| Pagamentos | Generic | Cobrança, repasse e confirmação financeira |
| Identidade e acesso | Generic | Login, identidade e controle de acesso |
| Notificações | Generic | E-mails, push e mensagens operacionais |
Essa classificação ainda pode mudar, porque ela depende da estratégia da empresa. Se amanhã o grande diferencial passar a ser a montagem inteligente de roteiros, Gestão de ofertas pode subir de importância e até se fundir com o core. O objetivo aqui não é congelar o desenho, e sim começar a enxergar onde vale investir nosso esforço.
Conclusão
No próximo artigo vamos continuar refinando nossos subdomínios e falar um pouco sobre linguagem ubíqua.
SOCIAL SHARE CARD GENERATOR