Booking Management System

Plataforma de reservas de imóveis (estilo Airbnb) em microsserviços, construída como projeto de estudo/portfólio para explorar, com profundidade real e não só de nome: DDD tático, prevenção de double-booking sob concorrência, e autenticação JWT distribuída sem gateway central.

O projeto está em andamento — o núcleo de disponibilidade e reservas é a parte mais madura; outras áreas (busca, pricing, reviews) ainda não existem. Veja Estado do projeto antes de assumir que algo está pronto.

Por que este projeto existe

A pergunta que ele tenta responder não é "dá pra fazer um clone de Airbnb", mas "onde complexidade de domínio real justifica DDD, e onde isso é só cerimônia". As respostas para essa pergunta, com as alternativas descartadas em cada caso, estão documentadas como ADRs — não como opinião solta.

Arquitetura

• docs/c4-arquitetura.md — diagramas C4 de Contexto e Container (quem usa o sistema, como ele se decompõe em serviços/bancos de dados reais).
• docs/deep-dive-disponibilidade.md — como o sistema evita reservar o mesmo imóvel duas vezes, incluindo o fluxo dinâmico de criação de reserva.
• Decisões de arquitetura (ADRs), uma por serviço:
  • apps/property-management/adr/ — modelagem de disponibilidade (intervalos, HOLD, janela de 12 meses, constraint transacional), guards de autorização por rota, e por que DDD tático é aplicado seletivamente.
  • apps/users-management/adr/ — estratégia de autenticação JWT (RS256 + JWKS, refresh token rotation).

Estrutura do repositório

Monorepo gerenciado com Turborepo + npm workspaces.

Cada serviço em apps/ segue Clean Architecture (domain/ → application/ → infrastructure/), mas com profundidades de modelagem diferentes — isso é deliberado, não inconsistência. Ver apps/property-management/adr/ADR-0007.

Stack técnica

Infra: Nginx como reverse proxy (apps/barrier-wall), Docker Compose para os bancos e Redis, Turborepo para orquestrar build/test/lint no monorepo.

Como rodar localmente

Pré-requisitos: Node ≥ 18, Docker.

npm run dev roda todos os serviços via Turborepo (cada um com tsx --watch). O Nginx (apps/barrier-wall/nginx.conf) espera os serviços em hostnames de container (ms-booking-instance-*, ms-auth-instance-*); para rodar tudo atrás do proxy é preciso containerizar os apps ou ajustar o upstream do Nginx para localhost — hoje o docker-compose.yml só sobe os bancos, o Redis e o Nginx, não os serviços Node (ver Estado do projeto).

Comandos úteis (rodam em todos os workspaces via Turborepo):

Destaques técnicos

• Prevenção de double-booking sem lock pessimista — modelo intervalar de disponibilidade, verificação transacional otimista e constraint de exclusão no Postgres. Cinco decisões registradas e conectadas em docs/deep-dive-disponibilidade.md. Este documento também é honesto sobre o que ainda é lacuna de infraestrutura, não só o que já funciona.
• Autenticação distribuída sem gateway central — cada serviço valida o próprio JWT (RS256) buscando a chave pública via JWKS; o Nginx só roteia por path. Decisão e trade-offs em apps/users-management/adr/ADR-0001.
• Isolamento de schema em testes de integração — cada execução de teste cria um schema Postgres próprio (test_<hex>) e o descarta ao final, permitindo runs paralelos sem conflito. Detalhado em REPORT-schema-isolation.md.
• DDD aplicado onde protege algo, não por padrão — ver ADR-0007.

Estado do projeto

Em andamento. Pendências conhecidas:

• booking-module (reservas) tem domínio e casos de uso implementados e testados, mas ainda não tem camada HTTP — não é possível criar uma reserva via API hoje.
• Itens de infraestrutura da garantia anti-double-booking (transação com retry, mapeamento de erro de constraint, job de limpeza de HOLD) estão listados em PENDENCIAS-INFRA.md.
• docker-compose.yml sobe bancos, Redis e Nginx, mas não os serviços Node — eles rodam via npm run dev fora de container por enquanto.
• Backlog de funcionalidades de produto (busca, pricing dinâmico, reviews, gestão de amenidades) em issues.md.