Por qué empiezo con un monolito modular (y no con seis microservicios)

En el artículo anterior cerré con una idea que todavía me sirve de brújula: el mapa completo no implica desplegarlo entero la primera semana. Lo que sí implica es no tirar todo en un controller. Y hay una trampa intermedia: creer que porque separaste repos ya separaste el dominio.

Spoiler: no siempre.

Dos formas de equivocarse

En arkano-banking-challenge me pasó lo de siempre cuando vas contra reloj: un servicio que hace de todo y un controller que lo sabe. Funcionó para entregar. Para explicar, no tanto.

Al reconstruir en fintech-core-platform el otro extremo me miraba desde el README: microservicios desde el día uno, diagrama enterprise, impresión en LinkedIn. Bonito en captura. Pesado de operar cuando eres tú solo con el teclado y sin trazas distribuidas montadas.

El punto medio que me convence ahora es aburrido de decir en conferencia pero honesto de mantener: un monolito modular. Un artefacto. Una PostgreSQL al inicio. Módulos que no se importan en diagonal y dominio que no conoce NestJS.

No es renunciar a microservicios. Es no pagar su factura antes de tiempo.

Cómo ordeno las capas (sin volver loco al árbol de carpetas)

No me gustan los posts que dibujan hexagonal con diez cajas vacías. En la práctica pienso en cuatro cosas:

El dominio dice qué está permitido: no suspendes una cuenta cerrada, no inventas reglas en el controller. La aplicación coordina: abrir cuenta, buscar por id. La infraestructura es PostgreSQL hoy, otro adapter mañana. La interfaz es HTTP, DTOs, validación de entrada.

NestJS vive abajo en interfaz e infra. Si ves @Injectable o TypeORM dentro de domain/, algo se rompió.

Un microservicio es otro binario con otro ciclo de release. Un monolito modular es el mismo proceso con paredes internas. Cuando Transfers llegue, quiero que sea un módulo que respete esas paredes — no un copy-paste del controller de Arkano.

Qué gano y qué dejo para después

Hoy me importa el ACID local, el stack trace que no salta entre pods, y poder testear Account.suspend() sin levantar Docker. Mañana — si el producto y el equipo lo piden — importará desplegar Transfers sin tocar Accounts.

Si mueves dinero entre bases de datos sin modelo de consistencia, vuelves a la pregunta del timeout del post anterior — solo que ahora el fallo es distribuido. No estoy ahí todavía. Estoy intentando que cuentas esté bien modeladas antes de discutir pods.

Lo que ya está en el repo

La Fase 0 no es un slide. Ya está en GitHub con esta forma:

apps/accounts-service/
├── accounts/
│   ├── domain/           # sin @nestjs, sin typeorm
│   ├── application/
│   ├── infrastructure/
│   └── interface/
libs/domain-common/

La entidad Account vive en dominio y defiende reglas, no es un DTO con getters:

export class Account {
  private constructor(
    readonly id: AccountId,
    readonly ownerName: string,
    private _status: AccountStatus,
    readonly createdAt: Date,
  ) {}
 
  static open(id: AccountId, ownerName: string): Account {
    return new Account(id, ownerName, AccountStatus.ACTIVE, new Date());
  }
 
  suspend(): void {
    if (this._status === AccountStatus.CLOSED) {
      throw new AccountClosedError(this.id);
    }
    this._status = AccountStatus.SUSPENDED;
  }
}

El use case habla con un puerto, no con TypeORM:

export class CreateAccountUseCase {
  constructor(private readonly repo: AccountRepositoryPort) {}
 
  async execute(command: CreateAccountCommand): Promise<AccountId> {
    const id = AccountId.generate();
    const account = Account.open(id, command.ownerName);
    await this.repo.save(account);
    return id;
  }
}

Y el controller — como prometí cuando hablamos del POST /transfer — solo pasa datos y devuelve respuesta:

@Post()
@HttpCode(HttpStatus.CREATED)
async create(@Body() dto: CreateAccountDto): Promise<AccountResponseDto> {
  const id = await this.createAccount.execute({
    ownerName: dto.ownerName,
  });
  return AccountResponseDto.fromId(id);
}

pnpm test corre tests de dominio y application sin base de datos. Swagger en /api/docs. Docker Compose levanta PostgreSQL en el puerto 5433. Nada de Kafka todavía. Nada de fraude. Bien.

La pregunta que siempre aparece en entrevista

"¿Cuándo partirías Accounts y Transfers?"

Yo no arranco con Kubernetes. Miro si hay dos equipos que necesitan publicar sin esperarse, si un contexto pide mucha más escala que otro, si ya tienes trazas y contratos de eventos que amorticen el dolor distribuido. Si no hay dos señales claras, me quedo con módulos fuertes dentro del mismo deploy.

Los ports que escribes hoy ayudan mañana: el use case no debería enterarse si el adaptador es TypeORM o un mensaje en un bus.

Qué sigue

Transferencias y ledger vienen en las siguientes fases en el mismo binario hasta que el dominio diga lo contrario. El próximo artículo es sobre dinero en código: centavos, bigint, y por qué el float me da mala espina en un core bancario.

En el post anterior dibujé las capas detrás de un POST /transfer. Aquí elegí dónde pongo el código mientras aprendo: un edificio, departamentos ordenados, un solo deploy por ahora.

Serie: makingcode.dev/series/fintech-core-platform
Anterior: Detrás de un POST /transfer
Código: github.com/AndresED/fintech-core-platform