Desenhar o sistema é
justificar decisões.

Quais compromissos moldam o sistema?

Integridade: duas aprovações concorrentes não podem produzir decisões incompatíveis. Segurança: uma organização não acessa dados de outra. Modificabilidade: alterar uma política de alçada não deve exigir mudar a interface, o banco e a integração por acoplamento acidental.

Operação: identificar a causa de uma falha de sincronização e reprocessá-la com controle. Disponibilidade, latência e recuperação exigem metas negociadas; não há números reais neste estudo.

O risco de projetar com premissas invisíveis.

Não conhecemos volume, frequência de mudança, tamanho da equipe, criticidade financeira, prazo de retenção, comportamento do ERP e orçamento operacional. Sem esses dados, qualquer escolha de filas, cluster, cache ou microsserviços seria uma hipótese — não a solução inevitável.

Critério: levantar perguntas e alternativas com as pessoas responsáveis. A arquitetura é uma decisão revisável, não uma promessa de complexidade antecipada.

Compras, identidade e integração não são a mesma responsabilidade.

O contexto Compras é dono do ciclo da solicitação e da invariante de decisão. Identidade/Autorização informa permissões vigentes; Integração ERP traduz eventos e contratos de um sistema externo. A divisão concreta precisa ser validada no domínio — não determinada pelo número de tabelas.

Não confundir: bounded context é limite de modelo e linguagem; não obriga banco ou deploy independente.

Domínio não deve importar o servidor HTTP ou o ORM.

Um caso de uso pode depender de contratos de repositório e de autorização. Controllers, Prisma, mensageria e adaptadores executam esses contratos na borda. A inversão de dependência é uma propriedade dos imports e responsabilidades efetivos, não da presença de diretórios chamados `domain` ou `application`.

Quando simplificar: nem todo módulo precisa de dez interfaces. Introduza uma abstração quando ela reduz acoplamento significativo, melhora testes ou protege uma variação plausível.

Uma implantação, módulos com limites explícitos.

Como funciona: módulos de Compras, Autorização e Integração coexistem num processo e podem compartilhar um banco com regras de ownership. As mudanças do estado de aprovação podem ocorrer em transação local; integração externa permanece fora desse limite.

Ganha: menor complexidade de deploy, rastreamento e coordenação de dados. Custa: acoplamento de release, necessidade de disciplina para impedir imports cruzados e eventual necessidade de extração futura.

Preferir quando: equipe enxuta, limites ainda em aprendizado e nenhum requisito concreto de implantação independente justifica a rede adicional.

Implantações separadas, falhas também separadas.

Como funciona: serviços possuem contratos e ciclo de deploy próprio; uma atualização entre bancos de serviços não se torna atômica por chamar uma API. Mudanças e eventos exigem versionamento, observabilidade distribuída e política de falhas.

Ganha: autonomia e escalabilidade de componentes quando fronteiras e operação estão maduras. Custa: latência de rede, consistência entre serviços, segurança de comunicação, testes de integração e administração de infraestrutura.

Preferir quando: há razões mensuráveis para isolamento de deploy/equipes ou necessidades distintas de escala e resiliência, com capacidade de operação correspondente.

Talvez seja melhor não construir um ERP adicional.

Se o ERP já oferece workflow de aprovação parametrizável, revisar seu comportamento e controles pode eliminar uma aplicação inteira. Uma API fina de integração ou automação também pode resolver o problema. Análise de licenciamento, aderência, limites e ownership define se é viável.

Armadilha: o entusiasmo com arquitetura própria não é justificativa para custo e superfície de ataque adicionais.

Uma matriz qualitativa, sem pontuação inventada.

Integridade local: favorece limites transacionais simples. Autonomia de release: favorece separação quando há equipes e contratos maduros. Falhas externas: existem em todas as opções. Operação: cresce com o número de processos, bancos e fronteiras remotas.

Decisão revisável: documentar atributos de qualidade, volume observado, limites da equipe, orçamento e gatilhos de extração antes de defender um estilo como definitivo.

Quem interage e o que está fora?

Mostre pessoas, sistema de compras, serviço de identidade e ERP. Nomeie relações e fronteiras de confiança. É possível compreender o risco de integração sem apresentar controllers, containers Docker ou tabelas.

Onde ficam API, interface e armazenamento?

Somente quando necessário, detalhe aplicação web, API e banco como containers lógicos do modelo C4. Um “container” no C4 não significa obrigatoriamente Docker. Defina responsabilidade, tecnologia quando justificada e modo de comunicação.

O que existe dentro da aplicação?

Um desenho posterior pode mostrar `AprovarSolicitacao`, política de alçada, repositório de solicitações e adaptador ERP. Use sequência/estado ou ER quando a questão for fluxo, concorrência ou dados; C4 não substitui essas perspectivas.

Uma legenda e palavras importam mais que ícones.

Nomeie responsabilidades e relações; descreva alternativas textualmente para quem utiliza leitor de tela. Mantenha diagrama sincronizado com ADRs e contratos. Um desenho desatualizado com muitas caixas pode causar mais risco que uma explicação curta.

O que precisa ser executado?

T-01: aprovar com alçada vigente. T-02: negar autoaprovação e acesso entre organizações. T-03: executar decisões concorrentes em banco real descartável. T-04: simular 503 e confirmação perdida do ERP. T-05: validar replay sem efeito duplicado.

Estado deste estudo: cenários especificados; nenhum teste de banco, integração ou deploy foi executado para esta página.

O deploy não é o fim do ciclo.

CI precisa demonstrar integridade dos contratos, migrations e testes. O release requer estratégia de reversão. Em operação, backlog pendente, latência, autorização negada e falha de sincronização devem ser observáveis por sinais vinculados aos requisitos, não por métricas decorativas.

Revisar decisão: crescimento de times e falhas, gargalo comprovado, exigência de autonomia ou mudança de orçamento podem invalidar a ADR inicial.

Da regra de negócio ao módulo.

Investigar linguagem ubíqua, bounded contexts, agregados e invariantes. Depois comparar organização modular e inversão de dependências em Clean/Hexagonal, com código e testes mostrando a consequência de cada escolha.

Quando a rede entra no domínio.

Estudar consistência, filas, event-driven, outbox, Saga, CQRS, event sourcing e contratos. Separar padrões de implementação, estilos arquiteturais e mecanismos operacionais para não criar uma falsa equivalência entre eles.

Design Patterns no ponto em que ajudam.

Investigar Strategy, State, Adapter e Facade no contexto do caso de compras. Mostrar código antes/depois, custo da abstração, alternativa simples, critérios de não uso e testes que protegem a mudança.

Como validar, entregar e operar.

Ligar decisões aos testes de concorrência, requisitos de autorização, CI/CD, observabilidade, SRE e recuperação. Uma arquitetura que ninguém consegue implantar ou depurar continua sendo uma hipótese incompleta.

Simon Brown — modelo C4.

Documentação do próprio modelo para níveis de zoom, notação flexível e delimitação do que os diagramas estruturais explicam.

Consultar C4 Model

Microsoft — Architecture Decision Records.

Referência para registrar contexto, opções rejeitadas, decisão, consequências e necessidade de revisão conforme o sistema evolui.

Consultar ADR

AWS — Transactional Outbox.

Descreve o problema de gravação em dois destinos, duplicatas e consumidores idempotentes. Não elimina necessidade de decisões sobre ordenação e reconciliação.

Consultar Outbox

Martin Fowler — pré-requisitos operacionais.

Uma perspectiva sobre as competências e o custo de operação exigidos por microsserviços. Não é regra absoluta; confrontar os argumentos com requisitos e situações contrárias.

Consultar análise