APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um microserviço organiza uma capacidade de negócio com responsabilidade clara sobre comportamento e dados. Dividir uma aplicação por controladores, lógica e tabelas pode apenas distribuir dependências antigas pela rede. Começa por mapear decisões, vocabulário e invariantes com quem conhece o domínio. A mesma palavra pode ter significados diferentes: conta de acesso e conta contabilística não precisam do mesmo modelo. Uma fronteira é útil quando permite alterar uma capacidade sem obrigar consumidores a conhecer a sua implementação. O tamanho do repositório e o número de containers não demonstram autonomia. Observa também dependências síncronas e necessidade de releases coordenadas.
Aplicação guiada
Num exercício fictício de fundos, avaliação e publicação de relatórios têm ritmos e regras distintos. Define o contrato que transmite um resultado aprovado, incluindo versão, referência e significado dos estados. Se cada cálculo exige dezenas de consultas remotas ao mesmo serviço, mede o custo e revê a fronteira ou a forma de obter dados. Não escolhas uma quantidade de serviços como objetivo de transformação. Regista quem mantém cada contrato, que consumidores o usam e como coexistem versões durante uma atualização gradual. Uma propriedade nova também merece análise se um consumidor rejeita campos desconhecidos. O teste deve representar consumidores reais e não apenas o produtor isolado.
Duas aplicações com deploys separados continuam acopladas se qualquer alteração exige uma release conjunta.
Armadilhas comuns
Serviço por tabela; autonomia deduzida do container; modelo único imposto a todos os contextos.
Tópicos relacionados: Dados e transações distribuídas · Resiliência e carga · Mensagens e filas
Desenha fronteiras a partir de decisões e contratos observáveis.
Referência: Domain analysis for microservices · Microservice architecture patterns and scoped platform examples; primary guidance consulted 2026-09-30