Visão geral da arquitetura

Resumo de uma arquitetura multi-repositório organizada em camadas para separar responsabilidades, facilitar a evolução e escalar com mais controle.

Objetivo desta arquitetura

A arquitetura proposta busca resolver um problema comum em sistemas que crescem:

• responsabilidades demais misturadas
• dificuldade para implantar sem risco
• integrações externas contaminando o domínio
• complexidade crescente no frontend e no backend
• acoplamento entre times e componentes

Para responder a isso, o sistema é organizado em camadas e serviços com limites mais claros.

A ideia não é adicionar complexidade por adicionar, mas sim distribuir a complexidade em lugares onde ela seja mais gerenciável.

As 7 camadas

1. Presentation

Aqui vive a interface do usuário. Renderiza telas, gerencia o estado, valida formulários do lado do cliente e consome APIs.

2. API Gateway

É a porta de entrada principal. Aplica autenticação, roteamento, rate limiting, logging e outras capacidades transversais.

3. BFF

Agrega e transforma dados para a UI. Reduz a complexidade do frontend e evita que o cliente conheça detalhes internos demais.

4. Microsserviços

Contêm a lógica de negócio organizada por domínios ou bounded contexts. Aqui vivem as regras, os casos de uso, os eventos de domínio e a persistência.

5. Event Bus

Permite a comunicação assíncrona entre serviços por meio de eventos. Favorece o desacoplamento temporal e a construção de processos distribuídos.

6. ACL

Protege o domínio de sistemas externos ou legados. Traduz modelos e encapsula adaptadores para não contaminar o core do negócio.

7. Data / External Systems

Inclui bancos de dados, cache, sistemas legados e provedores de terceiros.

Por que separar em camadas?

Separar em camadas permite:

Clareza de responsabilidades

Cada parte do sistema tem um foco mais específico.

Menor acoplamento

O frontend não precisa conhecer detalhes internos de cada microsserviço. Os serviços de domínio não deveriam depender diretamente do modelo de um ERP legado.

Escalabilidade técnica

Você pode escalar componentes diferentes conforme suas necessidades reais.

Escalabilidade organizacional

Os times podem trabalhar sobre áreas mais claras, com ownership definido.

Evolução controlada

Alterar uma peça afeta menos as demais se os limites estiverem bem definidos.

Comunicação entre camadas

Nesta arquitetura convivem duas grandes formas de comunicação:

Comunicação síncrona

É usada quando uma camada precisa de uma resposta imediata. Por exemplo:

• frontend → gateway
• gateway → BFF
• BFF → microsserviços

Normalmente ocorre por HTTP ou GraphQL/REST.

Comunicação assíncrona

É usada quando um serviço publica um fato e outros reagem sem necessidade de responder de forma imediata.

Por exemplo:

• ms-orders publica OrderPlaced
• inventory reage
• notifications reage
• analytics reage

Ambas convivem porque resolvem necessidades diferentes.

Multi-repo: por que separar repositórios

A arquitetura é pensada em múltiplos repositórios, um por camada ou por serviço principal.

Isso permite:

• independência de implantação
• ownership mais claro
• menor tamanho por repositório
• melhor isolamento por domínio

Mas também exige:

• padrões compartilhados
• acordos de versionamento
• disciplina com contratos
• controle do shared kernel

O multi-repo não é automaticamente melhor; é uma decisão que deve acompanhar uma necessidade real de separação.

Princípios que sustentam a arquitetura

Separação de responsabilidades

Cada camada resolve um problema diferente.

Domínio protegido

As regras de negócio devem viver no lugar certo e não se contaminar com modelos externos.

Contratos explícitos

A comunicação entre as partes do sistema deve estar definida e ser compreensível.

Evolução independente

Cada parte deve poder mudar com o mínimo de atrito possível.

Observabilidade e segurança desde o design

Não devem ser adicionadas no final como um remendo.

O que esta arquitetura não significa

É importante evitar algumas más interpretações.

Não significa que tudo deva ser um microsserviço

É preciso separar quando existe um limite claro e uma necessidade real.

Não significa que mais camadas seja sempre melhor

Cada camada deve justificar o valor que agrega.

Não significa que a complexidade desapareça

A complexidade não desaparece; ela é organizada melhor.

Não significa que o shared kernel possa crescer sem controle

Compartilhar demais pode recriar acoplamentos fortes.

Como percorrer esta seção

Recomendamos avançar assim:

1. Frontend
2. API Gateway
3. BFF
4. Microsserviços
5. Event Bus
6. ACL
7. Data / External Systems
8. Shared Kernel e contratos
9. Repositórios

Resumo

Esta arquitetura organiza o sistema em camadas com responsabilidades diferenciadas para favorecer a clareza, a escalabilidade e a evolução controlada. Não busca impor complexidade, mas posicionar cada tipo de complexidade no lugar onde ela possa ser mais bem gerenciada.