Mini Plataforma Fintech

Cómo levantar el proyecto

1. Variables de Entorno

Crear un archivo .env en la raíz del proyecto con el siguiente contenido (de referencia .env.example):

Nota: Se puede hacer directammente: $ cp .env.example .env

ENV=dev
PORT=3000

DB_HOST=localhost
DB_PORT=5432
DB_USERNAME=user
DB_PASSWORD=password
DB_DATABASE=wallet_db

2. Instalar Dependencias

Instalar dependencias usando:

npm install

3. Levantar la Base de Datos (Docker)

El proyecto utiliza PostgreSQL. Para mayor simpleza, cuenta con un archivo docker-compose.yml. Asegurarse de tener Docker instalado y ejecutándose, luego levantar el entorno de desarrollo usando el comando Make:

make dev

NOTA: El comando levanta el contenedor de Docker (up-docker) y luego iniciar la aplicación (npm run dev)

4. Correr los Tests

Para ejecutar los tests junto al reporte de cobertura, usar el comando:

make test

Este comando ejecuta npm run test:cov por detrás

---

Documentación (Swagger)

La especificación completa de la API se encuentra disponible en formato OpenAPI 3.0 en el archivo:

./docs/swagger.yaml

---

Resumen de la Estructura

La aplicación está construida siguiendo los principios de Clean Architecture, dividiendo el código en capas:

1. Domain (Dominio): Contiene el corazón de la aplicación. Modelos de dominio ricos (User, Transaction, LedgerEntry) que encapsulan la lógica de negocio, validaciones y cambios de estado. No tiene dependencias externas
2. Application (Casos de Uso): Contiene las reglas de negocio de la aplicación. Orquesta la interacción entre las entidades de dominio y los repositorios
3. Infrastructure (Infraestructura): Implementa las interfaces de las capas superiores, se encarga de la integración con libs externas

---

Algunas Consideraciones que se tuvieron en cuenta

• Idempotencia: Cada transacción de transferencia requiere un idempotencyKey único. Para simpleza del challenge se guarda en la base de datos, pero podría moverse a un Redis, haciendo uso de los TTLs.
• Auditoría y Trazabilidad (Ledger): Para auditoria de los movientos, por cada transferecia de fondos se genera una doble entrada en el ledger (only-append): resta en el emisor y suma en el receptor.
• Transacciones ACID: Toda la transferencia se envuelve en una transacción de la base de datos. Si algo se rompe en el medio del proceso, se hace Rollback automático.

---

Puntos de Mejora y Escalabilidad

A Nivel Código

• Separación del Repositorio: Actualmente, TypeOrmWalletRepository funciona como un repositorio gigante o Facade que maneja operaciones de Usuarios, Transacciones y Ledger al mismo tiempo. Lo ideal sería splitearlo en UserRepository, TransactionRepository y LedgerRepository.

A Nivel Arquitectura

• Procesamiento Asíncrono (Colas): Hoy en día la transferencia se procesa de manera sincrónica en el hilo principal. Si el sistema llegara a tener picos de millones de transacciones, mantener las conexiones abiertas a la base por cada Request podría bloquear el sistema. El next step sería encolar la intención de pago (ej. RabbitMQ, SQS, o Kafka) y tener workers que consuman la cola y ejecuten la operación correspondiente.
• Base de Datos Dedicada al Ledger: A medida que el sistema escale, la tabla de LedgerEntry crece de forma exponencial frente a los Usuarios