← All posts
1 min read
Clean Architecture in ASP.NET Core Without Over-Engineering
How to keep API, Core, and Infrastructure boundaries useful for real product teams — especially eCommerce and SaaS.
Clean Architecture helps when your domain rules must outlive UI frameworks and ORM choices. It hurts when every feature becomes six files of ceremony.
A pragmatic layout
- API — HTTP, auth, validation, mapping to requests/responses
- Core — entities, interfaces, domain services, specifications
- Infrastructure — EF Core, Redis, email, blob storage, Identity
Your eCommerce cart rules belong in Core. SQL tuning belongs in Infrastructure. Controllers stay thin.
Patterns that pay rent
- Repository + Specification for query composition (filters, paging, sorting)
- MediatR / CQRS-lite when command and query paths diverge meaningfully
- Result objects for expected business failures instead of exception-driven control flow
What I skip early
- Microservices on day one
- Perfect DDD ubiquitous language documents before the first user
- Abstractions with a single implementation and no test benefit
Client value
The point is changeability: swap Angular screens, keep domain rules; move from SQL Server to a read model without rewriting business policy.
That is the approach behind projects like Ecom_NET10 — and the same mindset I bring to client work. Hire me if you want it applied to your product.