3.2 Estilos e padrões arquiteturais

Visão geral e motivação

Um estilo arquitetural é uma forma ampla e reutilizável de organizar um sistema: como ele é decomposto, como as partes se comunicam e onde caem as fronteiras. Escolher um está entre as decisões mais consequentes (e mais mal compreendidas) que uma grande organização toma. Com demasiada frequência, a escolha segue a moda (“todo mundo está fazendo microsserviços”) em vez das restrições reais da equipe, do domínio e da realidade operacional. Você acaba com uma de duas bagunças: um sistema distribuído que a organização não consegue operar ou um monólito emaranhado que ninguém consegue mudar com segurança. Nenhuma das duas é culpa do estilo. Ambas vêm de desencaixar o estilo da situação.

Para equipes grandes de desenvolvimento, os estilos importam acima de tudo por causa da lei de Conway: a estrutura de um sistema tende a espelhar a estrutura de comunicação da organização que o constrói. Assim, um estilo arquitetural é também uma decisão de desenho organizacional. Dividir um sistema em serviços é, na verdade, uma decisão sobre dividir equipes, responsabilidades e sobreaviso. Empresas com centenas de engenheiros podem bancar (e muitas vezes precisam de) serviços de granularidade fina com implantação independente, porque essa independência é como muitas equipes entregam sem se bloquear umas às outras. Force o mesmo padrão sobre uma única equipe pequena e ela herda todo o imposto operacional sem nenhum benefício organizacional.

Os contextos governamental e corporativo empilham mais restrições: longas vidas dos sistemas, controle rigoroso de mudanças, ciclos de contratação, integração com sistemas de registro entrincheirados e auditabilidade. Isso favorece estilos que mantêm explícitas as fronteiras e fáceis de inspecionar as dependências. Este capítulo percorre os principais estilos: do monólito aos microsserviços, as arquiteturas orientadas a eventos com CQRS e event sourcing, os padrões de malha de serviços e de gateway, o serverless e as disciplinas internas da arquitetura hexagonal e limpa. Mais ainda, ajuda você a dizer quando cada um se encaixa.

Veja também: o capítulo 2.2 (princípios de design de software, incluindo o Domain-Driven Design), o capítulo 3.1 (fundamentos de arquitetura) e o capítulo 3.3 (sistemas distribuídos).

Princípios fundamentais

O estilo segue as forças, não a moda. Escolha com base no tamanho da equipe, na complexidade do domínio, na carga e na maturidade operacional, nunca porque uma tecnologia é popular.
O acoplamento é o verdadeiro inimigo, não o número de implantáveis. Um monólito bem modularizado vence uma grande bola de lama distribuída.
A distribuição é um custo que você paga pela independência. Só divida quando o valor da implantação, do escalamento ou do isolamento de falhas independentes superar o custo das chamadas de rede, da falha parcial e da consistência de dados entre serviços.
As fronteiras devem seguir o domínio de negócio. Alinhe serviços e módulos com contextos delimitados (cada um um modelo de domínio autocontido com sua própria fronteira explícita), não com camadas técnicas.
Projete bem o interior independentemente do exterior. A divisão em camadas hexagonal/limpa mantém a lógica de negócio independente de frameworks e de infraestrutura em todo estilo.
A lei de Conway é inescapável, então use-a. Projete juntos as fronteiras de equipe e a arquitetura.
Comece mais simples do que você acha que precisa. Você pode extrair serviços de um bom monólito modular. Desdistribuir uma bagunça prematura de microsserviços é muito mais difícil.

Recomendações

Adote por padrão um monólito modular. Divida com evidências

Comece a maioria dos sistemas como uma única unidade implantável com fortes fronteiras internas de módulo: interfaces claras, nenhum acesso aos dados de outro módulo e regras de dependência impostas. Você obtém transações simples, refatoração fácil e uma só coisa a implantar e a observar. Divida um módulo em seu próprio serviço apenas quando tiver uma razão concreta: uma parte que precisa escalar sozinha, uma equipe que precisa implantar em sua própria cadência, um domínio de falha que você precisa isolar ou um requisito de tecnologia diferente do resto. Quando dividir, divida ao longo das linhas dos contextos delimitados, para que cada serviço seja dono dos próprios dados e exponha um contrato estável.

Saiba quando os microsserviços merecem seu lugar

Os microsserviços dão implantabilidade independente, escalamento independente, isolamento de falhas e a liberdade de misturar tecnologias. Em troca, exigem CI/CD (integração contínua e entrega contínua) maduro, infraestrutura automatizada, rastreamento distribuído, descoberta de serviços e uma cultura de sobreaviso. Pergunte-se com honestidade: a sua organização consegue operar com confiabilidade em produção dezenas de serviços implantados de forma independente? Se a plataforma e a maturidade operacional não estão lá, os microsserviços apenas multiplicam os seus modos de falha sem entregar seus benefícios. Muitas organizações se dão melhor com um punhado de serviços de granularidade grossa alinhados aos principais domínios do que com um enxame de minúsculos.

Use a arquitetura orientada a eventos onde o desacoplamento e a assincronia compensam

A arquitetura orientada a eventos permite aos produtores emitir fatos sem saber quem os consome. Isso compra baixo acoplamento, um amortecedor para picos de carga e uma forma fácil de acrescentar novos consumidores. Use-a onde os fluxos de trabalho são naturalmente assíncronos e reativos. O CQRS (Command Query Responsibility Segregation) separa o modelo de escrita de um ou mais modelos de leitura, o que ajuda quando as cargas e as formas de leitura e escrita diferem acentuadamente. O event sourcing guarda o estado como um log de eventos somente de acréscimo em vez de como o estado atual, dando uma trilha de auditoria perfeita e viagem no tempo. Isso é poderoso para finanças e governo, onde “como chegamos a este valor?” é uma pergunta jurídica, mas acrescenta complexidade real no versionamento de eventos, na reconstrução de projeções e no raciocínio sobre consistência eventual. Recorra a eles de propósito, não por padrão.

Aplique padrões de gateway, BFF e malha para gerenciar muitos serviços

Um gateway de API dá aos clientes externos um único ponto de entrada, tratando a autenticação, a limitação de taxa, o roteamento e a terminação de TLS (Transport Layer Security). Um Backend-for-Frontend (BFF) dá a cada tipo de cliente (web, móvel, API de parceiros) a sua própria camada de agregação sob medida, evitando uma API inchada de tamanho único. Uma malha de serviços move as preocupações transversais (TLS mútuo, novas tentativas, tempos limite, deslocamento de tráfego e telemetria) para uma camada de infraestrutura em sidecar, para que as equipes de aplicação não precisem reimplementá-las. Acrescente uma malha apenas quando o número de serviços tornar ingerenciável tratar essas preocupações por serviço. Para poucos serviços, uma malha é mais peso operacional do que vale.

Pese o serverless com honestidade

As funções como serviço e as plataformas serverless gerenciadas tiram do seu prato a gestão de servidores, escalam a zero e cobram por uso, o que é ótimo para cargas irregulares, orientadas a eventos ou de linha de base baixa e para equipes pequenas. Os compromissos são reais: latência de partida a frio, limites de tempo de execução e de recursos, teste local mais difícil, possível aprisionamento a fornecedor e um custo que pode superar a infraestrutura provisionada em alto volume sustentado. Use o serverless onde sua economia e simplicidade operacional claramente vencem. Não force sistemas centrais estáveis e de alta vazão a ele por entusiasmo.

Mantenha limpa a lógica de negócio dentro de todo serviço

Qualquer que seja o estilo externo, mantenha limpo o interior com a arquitetura hexagonal (portas e adaptadores) ou limpa: regras de negócio no centro, dependendo apenas de abstrações, frameworks, bancos de dados e mensageria nas bordas como adaptadores substituíveis. Isso mantém a sua valiosa lógica de domínio testável sem infraestrutura e portável diante de mudanças de tecnologia: uma vantagem decisiva para sistemas governamentais e corporativos de longa vida que sobreviverão a várias gerações de frameworks.

Compromissos: prós e contras

Estilo	Melhor quando	Prós	Contras
Monólito modular	A maioria dos sistemas, especialmente no início	Operação simples, transações e refatoração fáceis	Unidade única de implantação. Escala como uma só. Risco de erosão
Microsserviços	Muitas equipes, alta escala, plataforma madura	Implantação e escalamento independentes, isolamento de falhas	Complexidade distribuída, consistência de dados, alto custo operacional
Orientado a eventos / CQRS / event sourcing	Fluxos assíncronos, necessidades de auditoria, escrita e leitura divergentes	Baixo acoplamento, auditabilidade, leituras escaláveis	Consistência eventual, versionamento de eventos, depuração mais difícil
Serverless	Trabalho irregular ou de linha de base baixa, orientado a eventos	Sem gestão de servidores, escala a zero, pagamento por uso	Partidas a frio, limites, aprisionamento, custo sob alta carga estável

O tema recorrente: você compra flexibilidade e independência com complexidade operacional e cognitiva. Os estilos distribuídos e orientados a eventos abrem mão da simplicidade de uma única pilha de chamadas e de uma única transação em troca da capacidade de escalar, implantar e falhar de forma independente. Essa troca compensa em escala e com uma plataforma madura. Sem uma, é ruinosa. As disciplinas internas (hexagonal/limpa) quase sempre valem a pena, porque custam pouco e mantêm abertas as suas opções de mudar de estilo depois.

Perguntas para discutir com sua equipe

Antes de dividir o próximo serviço, vocês dividirão a equipe que é dona dele, e quem tem autoridade para isso? A lei de Conway significa que uma fronteira de serviço é na verdade uma fronteira de equipe, então uma divisão que o organograma não sustenta produz um monólito distribuído: dois implantáveis, um trem de lançamento, um sobreaviso compartilhado. Numa grande empresa, a autoridade para remodelar equipes costuma ficar acima da engenharia, com linhas hierárquicas, finanças e RH, e é por isso que a arquitetura e o desenho organizacional precisam ser decididos juntos. Leve evidências à discussão: o serviço proposto tem uma equipe que consegue ser dona dele de ponta a ponta, compor o próprio sobreaviso e implantar na própria cadência? Se a resposta é não, ou financiem a equipe ou mantenham a capacidade como um módulo no monólito. Dividir o código sem dividir a responsabilidade compra todos os custos da distribuição e nenhuma da independência.
Vocês conseguem implantar cada um dos seus serviços de forma independente hoje, ou eles são entregues em sincronia, em segredo? O monólito distribuído é o pior desfecho deste capítulo: você paga por chamadas de rede, falha parcial e consistência de dados entre serviços, e ainda assim não consegue lançar um sem os outros. Os sinais reveladores são um banco de dados compartilhado, uma biblioteca compartilhada que força atualizações coordenadas e testes de integração que precisam rodar o parque inteiro junto. Para uma equipe grande isso limita em silêncio a vazão, porque todas as equipes fazem fila atrás de um só lançamento mesmo quando o diagrama mostra independência. Pegue uma mudança recente e conte quantos serviços precisaram ser implantados juntos para que ela fosse segura. Se esse número é maior que um para uma mudança que tocou uma única capacidade, as suas fronteiras estão erradas. A correção costuma ser dar a cada serviço os próprios dados e um contrato estável e versionado, não acrescentar mais serviços.
Quais das divisões de serviço que vocês já fizeram deixaram de compensar, e vocês as consolidariam de volta? O hábito mais avançado do capítulo é tratar as decisões de estilo como reversíveis: extrair quando surge um direcionador e refundir quando o direcionador desaparece. A maioria das organizações só divide, então os nanosserviços e os serviços de entidade tagarelas se acumulam até a orquestração e o custo de rede fazerem sombra ao trabalho que cada serviço faz. Procurem serviços que sempre são implantados juntos, que existem por causa de uma tabela de banco de dados e não de uma capacidade de negócio ou cujos saltos de rede agora dominam a latência de uma requisição. Em parques corporativos e governamentais, onde o quadro de pessoal e os orçamentos são escrutinados, dobrar dois serviços finos de volta num único serviço de granularidade grossa é uma jogada legítima e que economiza custos, não uma admissão de fracasso. Ponham a reconsolidação na mesa tão abertamente quanto a extração e decidam ambas com as mesmas evidências.
A maturidade da sua plataforma e do seu sobreaviso realmente sustenta o estilo que vocês propõem, e vocês conseguem nomear as lacunas específicas antes de se comprometer? Os microsserviços, as malhas e as espinhas dorsais orientadas a eventos só entregam seus benefícios sobre CI/CD maduro, rastreamento distribuído, descoberta de serviços e uma cultura de sobreaviso capaz de raciocinar sobre falha parcial. Uma grande organização tende a decidir o estilo-alvo num fórum de arquitetura e a descobrir a plataforma ausente depois, quando dezenas de serviços já estão em produção e cada incidente leva horas para ser diagnosticado. Pesem o apelo da implantação e do escalamento independentes contra a pergunta sóbria de quem opera isso às 3 da manhã: a mesma divisão que liberta as equipes para entregar em paralelo também multiplica os modos de falha que cada equipe precisa entender. Levem um inventário honesto à discussão: a frequência atual de implantação, o tempo médio de recuperação, se vocês têm rastreamento através das fronteiras de serviço e quantos serviços uma única equipe consegue realisticamente operar. Em contextos corporativos e governamentais, acrescentem os prazos de contratação e de pessoal para as capacidades de plataforma que lhes faltam, porque um estilo que pressupõe uma malha e uma equipe de plataforma que vocês não financiaram é um plano para operar um parque insustentável.
Para quais partes do domínio uma trilha de auditoria completa por event sourcing é uma necessidade legal e não uma conveniência, e quem tem autoridade para decidir? O event sourcing e o CQRS compram um histórico perfeito e reconstruível e modelos de leitura que escalam sozinhos, mas custam versionamento de eventos, reconstrução de projeções e raciocínio sobre consistência eventual durante toda a vida do sistema. Aplicada a um domínio que nunca precisou da trilha de auditoria, essa complexidade é puro imposto. Negada a um domínio em que “como chegamos a este valor?” é uma pergunta jurídica, a sua ausência é uma falha de conformidade. As considerações concorrentes são a auditabilidade e a escalabilidade das consultas de um lado e a dificuldade de depuração e a carga cognitiva do desenvolvedor do outro, então a decisão pertence a quem entende tanto a obrigação regulatória quanto o fardo operacional, não a quem mais se entusiasma com o padrão. Levem as exigências legais ou contratuais específicas de retenção e de reconstrução, o volume esperado de eventos e uma estimativa honesta do trabalho de versionamento e de projeção. Em finanças, impostos e governo, onde reconstruir uma decisão anos depois pode ser um dever legal, nomeiem o responsável que assina que um dado contexto delimitado exige, ou não, um log imutável de eventos.
Como vocês impedirão o monólito modular de se erodir para que a extração futura continue barata, e o que imporá as fronteiras? Todo o argumento para começar com um monólito modular repousa na promessa de que fronteiras internas limpas tornam acessível a extração posterior de serviços, mas essas fronteiras decaem em silêncio no momento em que um prazo tenta um módulo a acessar os dados de outro. Para uma equipe grande, com muitos contribuidores, as boas intenções e a revisão de código sozinhas não seguram a linha. Sem um mecanismo de imposição, o monólito vira em silêncio a grande bola de lama que o estilo pretendia evitar. Pesem o atrito de regras de dependência e interfaces de módulo impostas contra o custo de descobrir, anos depois, que nenhuma fronteira é real e que toda extração significa desembaraçar estado compartilhado. Levem evidências: as fronteiras de módulo são impostas por ferramentas de build, análise estática ou estrutura de pacotes, ou são meras convenções documentadas que os últimos seis merges ignoraram? Em sistemas corporativos e governamentais de longa vida, que precisam sobreviver a um controle rigoroso de mudanças e a várias gerações de frameworks, tratem a imposição das fronteiras como um controle auditável, para que a opção de distribuir depois seja uma que vocês de fato preservaram e não uma que presumem ainda ter.

Perspectiva por setor

Startup. Adote por padrão um único monólito modular e resista à atração dos microsserviços, porque seu recurso mais escasso é a atenção de engenharia e um enxame de serviços é um imposto operacional que você não pode bancar antes do encaixe produto-mercado. Mantenha fronteiras de módulo limpas para poder extrair depois e recorra ao serverless onde o escalamento a zero e o pagamento por uso servem à sua carga irregular e de linha de base baixa. Divida exatamente uma coisa apenas quando surgir um direcionador concreto, como um emissor de notificações em rajadas, e nunca antes.

Pequena empresa. Sem equipe de plataforma e com orçamento apertado, favoreça um monólito ou um punhado de serviços de granularidade grossa numa plataforma gerenciada e compre infraestrutura hospedada em vez de construir você mesmo malhas, rastreamento e descoberta de serviços. Pese o serverless e os bancos de dados gerenciados como forma de evitar totalmente rodar servidores e desconfie de um design distribuído cujo fardo operacional você não tem quem carregue. A arquitetura certa é a que uma ou duas pessoas conseguem de fato implantar, observar e recuperar.

Grande empresa. O problema real são muitas equipes e a lei de Conway: alinhe serviços de granularidade grossa aos contextos delimitados e à responsabilidade das equipes e invista deliberadamente na plataforma (CI/CD, rastreamento, malha e descoberta de serviços) que torna segura a distribuição. Padronize os padrões de gateway, BFF e arquitetura limpa interna para que os grupos parem de reinventá-los e governe a extração e a reconsolidação como decisões de portfólio baseadas em evidências e não como preferência local. Orce explicitamente o custo operacional de cada divisão, porque na sua escala a falha do monólito distribuído é cara e lenta de desfazer.

Governo. As longas vidas dos sistemas, o controle rigoroso de mudanças, os ciclos de contratação e a auditabilidade moldam a escolha: favoreça estilos com fronteiras explícitas e inspecionáveis e contratos duráveis que sobrevivam a fornecedores e a gerações de frameworks. O event sourcing merece sua complexidade onde reconstruir uma decisão voltada ao cidadão é um dever legal, então use-o deliberadamente para os livros-razão centrais e mantenha a arquitetura limpa dentro de cada serviço para isolar as regras que mudam a cada orçamento. Trate a portabilidade e a saída de plataformas proprietárias serverless ou de fornecedores como exigências de contratação, e não como reflexões tardias.

Exemplos

Startup. Uma startup de quatro pessoas que constrói um produto de agendamento sente a pressão de começar com microsserviços porque um concorrente escreveu sobre eles num blog, mas resiste. Entrega um único monólito modular com fronteiras internas claras (agendamento, cobrança, notificações) como módulos separados num só implantável, de modo que uma pessoa engenheira roda tudo localmente e um lançamento é um único push. À medida que o produto ganha tração, apenas o emissor de notificações, que se espalha para e-mail e SMS sob carga em rajadas, é puxado para um serviço próprio. Elas não herdam nada do imposto operacional de uma dúzia de serviços enquanto ainda caçam o encaixe produto-mercado.

Grande empresa. Uma grande empresa de comércio eletrônico começa como um monólito modular. À medida que o tráfego cresce e as equipes se multiplicam, ela retira os domínios de maior carga e de evolução mais independente (catálogo, carrinho, pagamento e busca) para serviços separados, cada um dono dos próprios dados. O pagamento emite eventos que estoque, atendimento e análise consomem por uma espinha dorsal de eventos, de modo que novos consumidores (detecção de fraude, fidelidade) podem se conectar sem tocar no pagamento. Um gateway de API trata a autenticação e a limitação de taxa, e um BFF adapta as cargas úteis para o celular. Os domínios restantes, de menor tráfego, ficam no monólito, o que evita uma fragmentação desnecessária.

Governo. Uma autoridade tributária constrói uma plataforma de apuração com event sourcing no livro-razão central, porque toda mudança na obrigação de um contribuinte precisa ser reconstruível e legalmente auditável por anos. Comandos (entregar declaração, aplicar pagamento, emitir ajuste) produzem eventos imutáveis, e modelos de leitura projetam os saldos atuais para os agentes e os cidadãos. O CQRS permite que o lado de consulta voltado ao público escale por conta própria no pico da temporada de declarações sem pôr em risco o lado de escrita. Por dentro, cada serviço segue a arquitetura limpa, de modo que as regras de apuração, que mudam a cada orçamento, ficam isoladas da tecnologia de persistência e de mensageria.

Justificativa de negócio: motivações, ROI e TCO

O dinheiro em jogo numa escolha de estilo é enorme, porque a decisão é cara de reverter. Adote microsserviços cedo demais e você infla o custo total de propriedade com a montagem da plataforma, infraestrutura duplicada, depuração distribuída e um fardo operacional mais pesado: custos que ficam com você por toda a vida do sistema. Recuse-se a dividir um monólito genuinamente sobrecarregado e você limita a vazão de entrega: as equipes fazem fila atrás de um lançamento compartilhado, e toda mudança põe o sistema inteiro em risco. A conversa sobre ROI é, na verdade, sobre ajustar o gasto operacional à necessidade organizacional.

Defenda o caso junto à liderança em termos de vazão e risco, não de tecnologia. A implantabilidade independente significa mais equipes entregando em paralelo e prazos de entrega mais curtos: velocidade de negócio mensurável. O isolamento de falhas significa menos quedas totais e um raio de impacto menor: disponibilidade e proteção da reputação mensuráveis. Mas seja igualmente honesto sobre o investimento de plataforma que cada estilo exige: uma malha, rastreamento e maturidade de CI/CD são pré-requisitos, não extras opcionais, e o custo deles pertence ao TCO. Para muitas organizações o caminho mais barato é um monólito bem modularizado agora, com fronteiras internas limpas que tornam barata a extração posterior. Isso compra a opção de distribuir sem pagar por ela antes de precisar.

Antipadrões e armadilhas

Monólito distribuído. Serviços que precisam ser implantados juntos e compartilham um banco de dados: todo o custo da distribuição, nenhuma independência.
Nanosserviços. Serviços tão finos que a orquestração e o custo de rede fazem sombra ao trabalho que fazem.
Microsserviços sem plataforma. Dividir antes de ter CI/CD, rastreamento e maturidade de sobreaviso. Os modos de falha se multiplicam.
Serviços de entidade. Dividir por tabela de banco de dados (“serviço de Usuário”, “serviço de Pedido”) em vez de por capacidade de negócio, forçando chamadas tagarelas entre serviços a cada operação.
Event sourcing em toda parte. Aplicá-lo a domínios que não precisam de uma trilha de auditoria, pagando o imposto da complexidade sem benefício.
Gateway como monólito. Pôr lógica de negócio no gateway de API, recriando um ponto central de estrangulamento.
Núcleo acoplado ao framework. Lógica de negócio emaranhada com o framework web ou de ORM (mapeamento objeto-relacional), tornando doloroso tanto o teste quanto a mudança de tecnologia.

Modelo de maturidade

Nível 1: Iniciar. O estilo é escolhido pela moda ou por acidente. Você tem um monólito emaranhado ou uma bagunça distribuída acidental, as fronteiras seguem camadas técnicas ou a história e não o domínio, e as divisões acontecem de forma reativa quando algo quebra.
Nível 2: Desenvolver. Algumas equipes traçam fronteiras deliberadas de módulo dentro do monólito ou montam alguns serviços de granularidade grossa, e algumas preocupações transversais são tratadas de forma consistente. A prática é desigual: um grupo alinha serviços a contextos delimitados enquanto outro ainda divide por tabela de banco de dados, e a extração continua ad hoc.
Nível 3: Padronizar. Uma abordagem documentada é imposta em toda a organização: os serviços se alinham a contextos delimitados e são donos dos próprios dados, os padrões de gateway e de BFF são usados onde apropriado, a divisão interna em camadas limpa ou hexagonal é o padrão e toda divisão exige um direcionador declarado. As fronteiras de módulo são impostas por ferramentas, não apenas por convenção.
Nível 4: Gerenciar. As decisões de estilo são medidas e controladas em relação a linhas de base. Você acompanha a frequência de implantação e o prazo de entrega por serviço, o tempo médio de recuperação, quantos serviços precisam ser implantados juntos para uma mudança típica e a latência dos saltos de rede, e compara o custo de cada divisão com a independência que ela pretendia comprar. A evidência, não a preferência, decide se uma fronteira sobrevive, e a deriva rumo a um monólito distribuído é pega por métricas e não por uma queda de serviço.
Nível 5: Orquestrar. A arquitetura é integrada ao desenho organizacional e continuamente adaptada. Uma plataforma madura (CI/CD, rastreamento e malha onde justificada) torna barata tanto a distribuição quanto a reconsolidação, as equipes rotineiramente extraem quando surge um direcionador e dobram serviços de volta quando um desaparece, e as escolhas de estilo são reequilibradas conforme a topologia das equipes, a carga e o quadro de riscos mudam em todo o parque.

Ideias para discussão

Onde, no seu sistema, um monólito é de fato uma força, e onde é um gargalo genuíno?
Que direcionador concreto justificaria extrair o seu próximo serviço, e vocês conseguem nomeá-lo antes de construir?
A sua organização tem a maturidade operacional que os microsserviços exigem? O que falta?
Para quais partes do seu domínio uma trilha de auditoria completa por event sourcing é uma necessidade legal ou de negócio versus um mero desejável?
Quão bem as suas fronteiras de serviço atuais espelham as fronteiras das suas equipes, e esse alinhamento está ajudando ou atrapalhando?
Se vocês tivessem de trocar o framework web ou o banco de dados no ano que vem, quanto da sua lógica de negócio teriam de reescrever?

Principais conclusões

Escolha o estilo arquitetural a partir de forças reais (tamanho da equipe, domínio, carga, maturidade operacional), não da moda.
Um monólito modular é o padrão certo para a maioria dos sistemas. Extraia serviços apenas com um direcionador concreto e ao longo das linhas dos contextos delimitados.
Os microsserviços trocam complexidade operacional e cognitiva por implantação, escalamento e isolamento de falhas independentes. Exigem uma plataforma madura.
O orientado a eventos, o CQRS e o event sourcing oferecem desacoplamento e auditabilidade ao custo de consistência eventual e complexidade de versionamento. Adote-os deliberadamente.
Os gateways, os BFFs e as malhas domam parques de muitos serviços mas acrescentam peso. Introduza-os quando a escala exigir, não antes.
Aplique a arquitetura hexagonal/limpa dentro de todo serviço para manter a valiosa lógica de negócio testável e durável diante de mudanças de tecnologia.

Referências e leitura complementar

Sam Newman, Building Microservices and Monolith to Microservices
Chris Richardson, Microservices Patterns
Eric Evans, Domain-Driven Design
Vaughn Vernon, Implementing Domain-Driven Design
Robert C. Martin, Clean Architecture
Alistair Cockburn, “Hexagonal Architecture (Ports and Adapters)”
Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
Martin Fowler, Patterns of Enterprise Application Architecture (and articles on CQRS and Event Sourcing)
Matthew Skelton and Manuel Pais, Team Topologies