Arquitetura do sistema (C4)

Este documento descreve o Booking Management System nos níveis 1 (Contexto) e 2 (Container) do modelo C4. Os diagramas refletem o que está realmente implementado no repositório hoje — não a arquitetura hipotética explorada em Arquitetura de microserviços para plataforma de reservas.md, que é material de brainstorm e inclui componentes (API Gateway dedicado, CQRS, Event Sourcing, observabilidade com Prometheus/Jaeger) que não foram construídos.

Para os níveis 3 (Component) e 4 (Code), veja o deep-dive do núcleo de disponibilidade — o único container com complexidade suficiente para justificar esse zoom é property-management, e ele já é coberto em prosa lá.

---

Nível 1 — Diagrama de Contexto

Quem usa o sistema e com quais sistemas externos ele conversa.

Legenda: caixas azuis = o sistema em desenvolvimento; caixas cinza = sistemas externos; caixas azul-escuro = atores humanos. Rótulos nas setas indicam o propósito da interação e o protocolo.

---

Nível 2 — Diagrama de Container

Como o sistema se decompõe em processos/serviços implantáveis de fato.

Legenda: cada container é um processo/deploy unit independente (ver docker-compose.yml). Rótulos nas setas descrevem o que trafega e o protocolo, não só a direção.

Notas sobre o que o diagrama mostra (e o que não mostra)

• property-management hospeda dois contextos internos: property-module (Property, Listing, disponibilidade) e booking-module (Reservation, Guest local ao contexto de reserva). Eles se comunicam por uma interface interna (PropertyModuleInterface), não por chamada de rede — por isso aparecem como um único container, não dois. Ver o deep-dive para o detalhe dessa fronteira.
• redis só é usado por users-management hoje (refresh token, estado OAuth, rate limiting). Ele não faz parte do mecanismo de HOLD de disponibilidade — isso é uma simplificação em relação ao que notes/availability-architecture.md descreve; os ADRs 0004/0005 de property-management/adr (que são a decisão vigente) optaram por verificação transacional no Postgres, sem Redis.
• booking-module ainda não tem camada HTTP: os casos de uso de reserva (create-reservation-use-case, confirm-reservation-use-case etc.) existem e são testados, mas nenhuma rota do Nginx ou controller expõe esse módulo publicamente ainda. Por isso o diagrama não desenha uma seta de nginx para reservas — ela ainda não existe.
• Não há gateway de autenticação centralizado. Cada serviço valida o próprio JWT (ver apps/users-management/adr/ADR-0001-estrategia-autenticacao-jwt.md). O Nginx só roteia por path.