OpsFlow API
Implemented
Context
A REST API for fictional internal commercial operations. The entire domain is synthetic and does not represent an employer system, a real company, or an existing commercial integration.
Problem
The API brings customers, products, inventory, orders, payments, authentication, authorization, and auditing together in one maintainable backend.
My role
I implemented the API MVP, persistence, business rules, validation, authorization, tests, and CI automation within the public repository scope.
Technical decisions
- I used ASP.NET Core and EF Core with PostgreSQL for the backend and persistence.
- I kept clear boundaries between the API, application, domain, and infrastructure projects.
- I used PostgreSQL transactions for order confirmation, inventory, payments, and audit events.
- I represented errors with RFC Problem Details and tested persistence against real PostgreSQL.
What was built
- Customers, products, inventory, orders, payments, users, roles, and auditing.
- ASP.NET Core Identity and JWT Bearer authentication, with role-based authorization.
- EF Core migrations, pagination, filters, OpenAPI in Development, Docker Compose, and CI.
- Unit tests and integration tests against real PostgreSQL.
Architecture
The solution is organized into OpsFlow.Api, OpsFlow.Application, OpsFlow.Domain, and OpsFlow.Infrastructure. The API coordinates HTTP; infrastructure connects EF Core, PostgreSQL, Identity, and the synthetic seed.
Rules and security
The repository documents rules for products, inventory, orders, and payments, together with authentication, Admin and Operator roles, Problem Details errors, and auditing of critical operations.
Testing and CI
Public validation includes unit tests, PostgreSQL integration tests through Testcontainers, build checks, repository checks, and a GitHub Actions workflow.
Limits
- The domain and data are synthetic.
- It does not include a frontend, a payment provider, or connections to external services.
- The repository documents local security and deployment limits; it is not presented as a hardened production system.
Result
The API MVP is implemented and documented in the public repository, with tests, CI, and a reproducible local workflow.
What I learned
- Business rules and their transactions should remain visible in the architecture.
- Tests against a real database reveal different problems than unit tests.
- Documenting limits avoids presenting a synthetic backend as a real operational product.
Technologies
- C#
- .NET
- ASP.NET Core
- PostgreSQL
- EF Core
- Docker
- GitHub Actions
- xUnit