Arquitetura Moderna: trade-offs, ADRs, C4 e evolução

# Exemplo de monolito modular em Node (estrutura típica)
src/
├── modules/
│   ├── billing/
│   │   ├── domain/            # entities, value objects, business rules
│   │   ├── use-cases/         # application services
│   │   ├── adapters/          # in/out: HTTP controller, DB repo, events
│   │   └── index.ts           # ONLY public API of this module
│   ├── catalog/
│   │   └── ... mesma estrutura
│   ├── identity/
│   │   └── ...
│   └── shared/
│       └── ...                # kernel: errors, clock, logger, IDs
├── infrastructure/
│   ├── db/                    # postgres client, migrations
│   ├── queue/                 # sqs/rabbit/kafka client
│   └── http/                  # fastify app setup
├── main.ts                    # composition root
└── fitness/                   # testes arquiteturais

# ADR 0007: Adotar monolito modular para o backend V1

**Status:** Accepted
**Data:** 2026-04-16
**Deciders:** @fernando, @maria, @joao

## Contexto
Vamos começar o backend do produto Y. Time atual: 4 engs. Domínio
claro (CRM para pequenas empresas) mas ainda imaturo. Prazo: MVP em
3 meses.

## Opções consideradas
1. Monolito tradicional (tudo misturado)
2. Monolito modular (módulos com fronteira, 1 deploy)
3. Microserviços desde o dia 1
4. Serverless first (Lambda + DynamoDB)

## Decisão
Opção 2: monolito modular. Node 20 + Fastify + Postgres + Redis.
Módulos: identity, billing, deals, contacts.

## Justificativa
- Time pequeno: operar >1 deploy seria overhead.
- Domínio imaturo: muita fronteira vai mudar; modular reduz custo de
  reorganizar.
- Prazo curto: otimizar pra velocidade de aprender, não pra escala.
- Quando crescer (100k users ou 15+ devs): reavaliamos em novo ADR.

## Consequências
- + Simplicidade operacional.
- + Uma stack só.
- + Consistência transacional dentro do monolito.
- - Escalabilidade horizontal por módulo mais difícil.
- - Release acoplado entre módulos (ao menos para V1).

## Referências
- "Modular monolith" (Kamil Grzybek)
- Shopify case study
- Related ADRs: 0005 (stack), 0006 (Postgres)

@startuml
!include <C4/C4_Container>

Person(user, "Cliente", "Usuário final da loja")
System_Boundary(store, "E-commerce") {
  Container(web, "Web app", "Next.js", "UI pública")
  Container(api, "API", "Fastify/Node", "Regras de negócio")
  ContainerDb(db, "Postgres", "RDS Aurora", "Pedidos, usuários, catálogo")
  Container(queue, "Queue", "SQS", "Eventos de pagamento")
  Container(worker, "Worker", "Node", "Processa pagamentos async")
}
System_Ext(stripe, "Stripe", "Gateway de pagamento")

Rel(user, web, "usa", "HTTPS")
Rel(web, api, "chama", "HTTPS/JSON")
Rel(api, db, "lê/escreve", "SQL")
Rel(api, queue, "publica", "AWS SDK")
Rel(worker, queue, "consome", "AWS SDK")
Rel(worker, stripe, "chama", "HTTPS")
@enduml

// fitness/no-cross-module-imports.test.ts
import { describe, it, expect } from 'vitest';
import fg from 'fast-glob';
import fs from 'node:fs/promises';
import path from 'node:path';

// Regra: módulo X só pode importar de shared/ ou do próprio X.
// Nunca de internals de módulo Y.

describe('fitness: module boundaries', () => {
  const modules = ['billing', 'catalog', 'identity'];

  for (const mod of modules) {
    it(`${mod} does not import other modules' internals`, async () => {
      const files = await fg(`src/modules/${mod}/**/*.ts`);
      const violations: string[] = [];
      for (const f of files) {
        const src = await fs.readFile(f, 'utf8');
        const m = src.match(/from ['"]@\/modules\/([a-z]+)\/(?!index['"])[^'"]+['"]/g);
        if (m) violations.push(`${f}: ${m.join(', ')}`);
      }
      expect(violations).toEqual([]);
    });
  }
});

// fitness/build-time.test.ts
import { execSync } from 'node:child_process';
it('build completes in under 90 seconds', () => {
  const t0 = Date.now();
  execSync('npm run build', { stdio: 'ignore' });
  const elapsed = Date.now() - t0;
  expect(elapsed).toBeLessThan(90_000);
});