CleanERP

Overview

CleanERP is an ERP practice project aimed at manufacturing and distribution workflows, with the current emphasis on getting the backend architecture right before the feature surface grows. The solution is organized around explicit boundaries between Presentation, Composition Root, Application, Domain, Infrastructure, and Persistence, so new modules can be added without turning the codebase into a tightly coupled API. Rather than treating architecture as a diagram-only concern, the project pushes those decisions into real request flow, service registration, result handling, diagnostics, and deployment setup.

Responsibilities

• Structured the solution into Presentation, Composition Root, Application, Domain, Infrastructure, and Persistence projects to keep responsibilities explicit as the ERP grows.
• Implemented a composition-root entry point so `Program.cs` stays thin while dependency registration and module wiring are centralized behind `AddCleanERP(...)`.
• Shaped request flow around controllers, MediatR, application handlers, repositories, mapping, and result objects so reads and writes follow a predictable CQRS-style path.
• Set up cross-cutting pipeline behaviors for logging, performance, validation, caching, auditing, notifications, and retry concerns instead of scattering them across handlers.
• Added Swagger, health checks, and Docker-ready setup so the project is easier to inspect, test, and evolve like a real service rather than a throwaway demo.

Technical Highlights

• Request and command flow is modeled explicitly: controller -> MediatR -> application handler -> repository/unit of work -> result handling.
• Composition root keeps startup clean while allowing modular service registration for a larger ERP dependency graph.
• Pipeline behaviors handle cross-cutting concerns in one place instead of duplicating validation, logging, and resilience logic across features.
• Persistence layer includes unit-of-work, auditing hooks, and domain-event dispatch patterns that better match enterprise backend expectations.

Challenges

• Designing the flow so new ERP modules can plug into the same architectural path without eroding the boundaries between API, application logic, and persistence.
• Keeping the structure disciplined enough for enterprise-style growth without overengineering the project into something impossible to iterate on.
• Treating operational concerns such as exception handling, health checks, auditing, and diagnostics as part of the architecture from the beginning.

Outcomes

• Produced a stronger ERP backend foundation than a typical CRUD practice project by making architecture, request flow, and cross-cutting concerns part of the implementation.
• Created a realistic base for expanding into inventory, manufacturing, sales, finance, and HR modules without needing to redesign the project structure later.