Aceito Data: 2026-08-17
Nota: este ADR é retrospectivo. A decisão já está refletida na estrutura de código de ambos os
serviços desde as primeiras versões; este documento formaliza um raciocínio que até agora só
existia informalmente (ver Filosofia de desenvolvimento dos microserviços.md, que discute a
mesma pergunta para um conjunto maior de microsserviços hipotéticos). Aqui a decisão é escrita
para os dois serviços que de fato existem no repositório.
O monorepo tem dois serviços de aplicação com modelos de domínio: property-management e
users-management. Os dois usam a mesma base (Class<Props> de @repo/core, Result/Either
para erros, injeção via Awilix), mas divergem na profundidade do modelo tático de DDD:
property-management, o aggregate Listing implementa isAvailableFor, placeHold,
confirmReservation, releaseInterval, blockPeriod, cleanupExpiredHolds, e existem
objetos de regra dedicados (domain/rules/interval-within-sliding-window-rule.ts,
reservation-min-duration-rule.ts, cancellation-window-rule.ts), cada um com testes
próprios.users-management, Host e Guest expõem só create, update, delete — wrappers
finos sobre os props, sem regras de negócio próprias além de validação de formato (via value
objects como Email, Phone). Não existe domain/rules/ nesse serviço.Isso não é inconsistência acidental — é o resultado de aplicar DDD tático onde o domínio tem invariantes reais para proteger, e não aplicá-lo onde não tem.
Forças em jogo:
Aplicar o mesmo nível de modelagem (aggregates com invariantes, objetos de regra, value
objects ricos) em users-management também.
Vantagens
Desvantagens
users-management hoje é essencialmente CRUD de perfis + emissão/validação de JWT — não há
invariante de negócio não-trivial para um aggregate proteger (o "domínio difícil" desse
serviço é criptografia e rotação de token, já tratado no ADR-0001 dele, não modelagem de
entidade)UPDATE ... WHERE id = ?property-managementTratar Listing, Property etc. como registros com getters/setters, movendo toda a lógica de
disponibilidade (checagem de sobreposição, expiração de HOLD, janela deslizante) para os casos
de uso ou para consultas SQL diretas.
Vantagens
Desvantagens
Listing muda de estado — espalhar isso pelos
casos de uso replica a mesma checagem em múltiplos lugares e é fácil esquecer umaListing) onde "o que é uma transição de estado válida" é
decididoAplicar aggregates com comportamento e objetos de regra em property-management (núcleo:
disponibilidade e reservas), e manter users-management como modelo simples com
create/update/delete, delegando a complexidade real desse serviço (tokens, criptografia,
revogação) para a camada de infraestrutura/aplicação, não para o modelo de domínio.
Vantagens
users-management permanece simples de ler e revisar — não há aggregate fingindo proteger
uma invariante que não existeusers-management está em infrastructure/auth (JWT, JWKS, rotation), não em domain/Desvantagens
users-management ganhar regras de negócio genuínas no futuro (ex: políticas de
verificação de identidade, limites de contas por host), a estrutura atual não tem onde
colocá-las sem refatoraçãoModelagem tática de DDD (aggregates com comportamento, objetos de regra dedicados, value
objects ricos) é aplicada em property-management, especificamente nos módulos que protegem
invariantes de disponibilidade e reserva. users-management mantém um modelo de domínio
propositalmente simples (CRUD sobre entidades de perfil), porque sua complexidade real está na
camada de autenticação, já coberta pelo ADR-0001 desse serviço.
O critério para decidir, caso um terceiro serviço seja adicionado ao monorepo: existe uma invariante de negócio que pode ser violada por uma sequência errada de operações? Se sim, justifica um aggregate rico. Se a "regra de negócio" é só validação de formato ou uma transição de status sem consequência para outras entidades, um modelo simples basta.
Listing continua sendo o único lugar que decide se uma transição de disponibilidade é
válida, o que os ADR-0001 a ADR-0005 pressupõemusers-management permanece legível para quem só precisa entender fluxo de CRUDusers-management acumular regras de negócio informalmente (validações espalhadas em
casos de uso, por exemplo) em vez de reconhecer o ponto em que merece um aggregate, o
serviço pode acabar com lógica de domínio real sem um lugar único que a proteja — o mesmo
problema que a Alternativa B tentava evitar em property-management