OpsFlow API
Implementado
Contexto
API REST para operaciones comerciales internas ficticias. Todo el dominio es sintético y el proyecto no representa un sistema de un empleador, una empresa real ni una integración comercial existente.
Problema
La API coordina clientes, productos, inventario, órdenes, pagos, autenticación, autorización y auditoría dentro de un backend mantenible.
Mi participación
Implementé el MVP de la API, su persistencia, reglas de negocio, validación, autorización, pruebas y automatización de CI.
Decisiones técnicas
- Usé ASP.NET Core y EF Core con PostgreSQL para el backend y la persistencia.
- Separé la API, la aplicación, el dominio y la infraestructura.
- Usé transacciones de PostgreSQL para confirmar órdenes, actualizar inventario, registrar pagos y guardar auditoría.
- Validé errores con RFC Problem Details y probé la persistencia contra PostgreSQL real.
Qué se construyó
- Clientes, productos, inventario, órdenes, pagos, usuarios, roles y auditoría.
- Autenticación con ASP.NET Core Identity y JWT Bearer, además de autorización por roles.
- Migraciones EF Core, paginación, filtros, OpenAPI en Development, Docker Compose y CI.
- Pruebas unitarias y de integración contra PostgreSQL real.
Arquitectura
La solución se organiza en OpsFlow.Api, OpsFlow.Application, OpsFlow.Domain y OpsFlow.Infrastructure. La API coordina HTTP; la infraestructura conecta EF Core, PostgreSQL, Identity y los datos sintéticos.
Reglas y seguridad
El repositorio documenta reglas para productos, inventario, órdenes y pagos, además de autenticación, roles Admin y Operator, errores Problem Details y auditoría de operaciones críticas.
Pruebas y CI
La validación incluye pruebas unitarias, pruebas de integración con PostgreSQL mediante Testcontainers, build, checks de repositorio y un workflow de GitHub Actions.
Límites
- El dominio y los datos son sintéticos.
- No incluye frontend, proveedor de pagos ni conexiones a servicios externos.
- El repositorio documenta los límites de seguridad y despliegue local; no se presenta como un sistema listo para producción.
Resultado
El MVP está implementado y documentado en el repositorio público, con pruebas, CI y un flujo local reproducible.
Qué aprendí
- Las reglas de negocio y sus transacciones deben ser visibles en la arquitectura.
- Las pruebas contra una base de datos real aportan información distinta de las pruebas unitarias.
- Documentar los límites evita presentar un backend sintético como un producto operativo real.
Tecnologías
- C#
- .NET
- ASP.NET Core
- PostgreSQL
- EF Core
- Docker
- GitHub Actions
- xUnit