Um sistema pode ter uma única aplicação em produção e ainda organizar suas responsabilidades com clareza. Quando tudo depende de tudo, a primeira necessidade pode ser separar regras e dados dentro do próprio sistema. Distribuir o código em vários serviços antes disso pode apenas espalhar o acoplamento.
Encontre fronteiras na operação
Observe áreas como pedidos, estoque e atendimento. Quais decisões pertencem a cada uma? Quem pode alterar seus dados? Quais informações as outras áreas precisam consultar? Essas perguntas ajudam a definir módulos por responsabilidade de negócio, em vez de apenas dividir arquivos por tecnologia.
Comece por uma fronteira que a equipe compreenda e consiga testar. O objetivo é tornar uma mudança local mais previsível, com dependências explícitas e regras que não precisam ser procuradas em vários lugares.
Defina como os módulos conversam
Um módulo pode expor operações específicas e manter seus detalhes internos protegidos. Se qualquer parte do sistema altera diretamente seus dados, a separação existe apenas no nome. Combine interfaces e responsabilidades de atualização.
- Quem decide a transição de estado de um pedido?
- Quem verifica a disponibilidade de estoque?
- O que acontece quando uma etapa depende de outra?
- Quais dependências precisam ser evitadas para não formar ciclos?
Mantenha a mudança pequena
Proteja o comportamento com testes, organize uma área e confira o impacto nas demais. Preserve um caminho de implantação que a equipe consiga operar. Uma reorganização extensa, sem resultados intermediários, dificulta descobrir onde uma regressão começou.
Documente decisões essenciais e exemplos de uso das interfaces. Regras de arquitetura podem ser verificadas no projeto, mas precisam corresponder a problemas reais de manutenção.
Distribua quando houver um motivo concreto
Um módulo pode precisar de escala diferente, isolamento de falhas ou ritmo de entrega próprio. Esses motivos merecem análise. Criar um serviço também acrescenta comunicação em rede, implantação, monitoramento e tratamento de falhas entre processos.
Martin Fowler discute o valor de começar com uma estrutura mais simples enquanto as fronteiras do domínio ainda estão sendo descobertas. Isso é uma orientação de arquitetura, não uma regra universal. A decisão precisa considerar o sistema e a capacidade da equipe que vai mantê-lo.
Avalie o efeito na próxima alteração
Depois de organizar um módulo, observe se a equipe consegue mudar sua regra sem tocar em partes inesperadas. Se as responsabilidades e os contratos ficaram mais claros, existe uma base melhor tanto para continuar com uma aplicação única quanto para extrair um serviço quando a necessidade surgir.
Leitura complementar: Monolith First, de Martin Fowler.
