Microsserviços, DDD, CQRS e companhia: o que cada termo realmente significa

Arquitetura de software tem um problema de vocabulário. Os termos viram modismo de apresentação antes de alguém explicar o problema real que resolvem — e o efeito colateral é previsível: times adotam a técnica pelo nome, não pelo motivo.

A consequência é direta: microsserviço vira padrão automático mesmo quando o time é pequeno demais pra sustentar a complexidade operacional que vem junto. Evento vira a resposta pra tudo, mesmo quando uma chamada síncrona simples resolveria com menos peça em movimento. Este é um guia direto pelos grandes temas — o que cada um resolve, e o custo que ele cobra em troca.

Microsserviços

É dividir um sistema grande em serviços pequenos, independentes, cada um dono de um pedaço específico do negócio — e do próprio banco de dados. O ganho é poder implantar, escalar e trocar cada pedaço sem mexer no resto. O custo é que agora existe uma rede distribuída no meio do caminho: latência, falhas parciais e consistência deixam de ser detalhe de implementação e viram o problema principal do dia a dia da equipe.

Event-Driven

Em vez de um serviço chamar o outro diretamente e esperar resposta, ele publica um evento — "pedido criado", "pagamento aprovado" — e quem tiver interesse reage, sem que o publicador saiba quem está ouvindo. Isso desacopla os serviços no tempo e na topologia. Em troca, uma chamada síncrona fácil de rastrear vira um fluxo assíncrono que exige observabilidade séria só pra responder "o que aconteceu depois do quê".

Domain-Driven Design (DDD)

DDD é uma forma de modelar software em torno do negócio, não do banco de dados. As ideias centrais: Bounded Context (contexto delimitado) — cada parte do sistema tem seu próprio vocabulário e regras, sem tentar unificar tudo num modelo só —, Aggregate (agregado) — um conjunto de objetos que muda de estado como uma unidade, garantindo consistência —, e Ubiquitous Language (linguagem compartilhada) — o time técnico e o time de negócio usam as mesmas palavras pra falar da mesma coisa. Sem isso, código e negócio divergem com o tempo até ninguém mais confiar no nome das coisas.

Cloud & Infra

É a camada de decisões sobre onde e como o sistema roda: AWS, GCP, Azure, contêineres, redes, políticas de acesso. O conjunto de boas práticas mais citado aqui é o Well-Architected, da AWS, que organiza essas decisões em pilares — confiabilidade, segurança, custo, performance, operação. Na prática, isso significa tratar infraestrutura como decisão de arquitetura desde o início, não como reparo depois que algo quebrou em produção.

Diagramas

C4, PlantUML, Mermaid, sequence diagrams: são formas diferentes de responder à mesma pergunta — "como as peças desse sistema se encaixam?" — em níveis diferentes de zoom. Um diagrama C4 de contexto mostra o sistema visto de fora; um sequence diagram mostra a troca de mensagens entre dois componentes específicos. Escolher o nível de zoom errado é a razão mais comum de diagrama que ninguém entende, ou que ninguém atualiza depois da primeira semana.

ADR (Architecture Decision Record)

É um documento curto que registra uma decisão de arquitetura, o contexto que levou a ela e as alternativas descartadas — e por quê. O valor não está na decisão em si, está na memória do porquê. Sem ADR, seis meses depois alguém propõe reverter uma decisão sem saber que ela já foi tentada e abandonada por um motivo específico — e o time repete o mesmo debate do zero.

Segurança

Mapear ameaças antes que elas aconteçam (threat modeling), confiar em ninguém por padrão (zero-trust) e seguir o catálogo de falhas mais comuns em aplicações web mantido pela fundação OWASP: é a disciplina de assumir que qualquer componente pode ser comprometido, e desenhar o sistema pra limitar o dano quando isso acontecer — não só tentar impedir que aconteça. Zero-trust, em particular, inverte a lógica clássica de "dentro da rede é seguro": cada chamada é verificada, ponto, independente de onde ela parte.

CQRS & Saga

CQRS — sigla de Command Query Responsibility Segregation, ou separação de responsabilidade entre comando e consulta — separa o caminho de escrita do caminho de leitura, cada um otimizado pro seu próprio padrão de uso, em vez de um modelo único tentando servir os dois bem ao mesmo tempo. Saga resolve o problema que aparece quando uma transação precisa atravessar vários serviços: em vez de uma transação distribuída clássica — frágil e lenta —, a saga quebra a operação em passos locais, cada um com uma ação de compensação caso algo dê errado no meio do caminho.

Agentes de IA

Orquestração multi-agente e uso de ferramentas pelo modelo: é a categoria mais nova da lista, e trata de como sistemas de IA decidem e executam ações — não só respondem perguntas. O tema central aqui é o mesmo dos outros oito: dar autonomia sem perder controle sobre o que pode dar errado.

Perguntas frequentes

Preciso conhecer todas essas categorias pra tomar uma boa decisão de arquitetura?

Não preciso conhecer todas em profundidade, mas preciso saber que existem — e reconhecer quando um problema específico pede uma delas. A maioria dos erros de arquitetura vem de aplicar uma técnica fora do contexto em que ela resolve algo, não de desconhecer a técnica em si.

Essas categorias competem entre si ou se combinam?

Se combinam, na prática. Um sistema de microsserviços real quase sempre usa event-driven pra parte da comunicação entre serviços, DDD pra desenhar os limites de cada um, e ADR pra documentar por que cada escolha foi feita daquele jeito.

Qual o fio que conecta todas elas?

Nenhum desses termos é bala de prata. Cada um existe porque resolve um problema específico, e cobra um custo específico em troca. Entender o problema por trás do nome é o que separa usar a técnica certa na hora certa de colecionar modismo em apresentação.