Most .NET projects don’t fail because of bad code.
They fail because of unclear structure.
When everything is dumped into a single project or loosely organized folders, things feel fine at first — until the project grows. Then small changes start breaking unrelated parts, testing becomes painful, and onboarding new devs turns into a mess.
Over time, I’ve converged on a simple structure that avoids most of these problems without overengineering.
Here’s how I structure almost every .NET project.
The core idea: separation of responsibility
The goal isn’t “complex architecture.”
It’s predictable boundaries.
Each part of the system should have one reason to change.
So I split my projects into 4 layers:
API
Application
Domain
Infrastructure
1. Domain layer (the center of everything)
This is the core of the system.
It contains:
Entities
Value objects
Domain rules
Core business logic
No dependencies on anything external.
Example:
User
Order
Invoice
The rule here is simple:
If you remove everything else, this should still make sense.
2. Application layer (use cases)
This is where the business workflows live.
It contains:
Use cases (CreateOrder, RegisterUser, etc.)
Interfaces (contracts)
DTOs
Validation logic
This layer defines what the system does, not how it does it.
It depends on the Domain layer, but nothing else.
3. Infrastructure layer (implementation details)
This is where external systems live:
Database (EF Core, Dapper)
Email services
File storage
External APIs
This layer implements interfaces defined in Application.
Example:
IEmailService → implemented here
IUserRepository → EF Core implementation here
This keeps your core logic independent from frameworks.
4. API layer (entry point)
This is the thin outer layer.
It contains:
Controllers / endpoints
Dependency injection setup
Request/response handling
Its job is simple:
Receive input → call Application → return output
No business logic should live here.
Why this structure works
This setup gives you:
Clear boundaries between concerns
Easier testing (especially Application layer)
Swap database or services without touching business logic
Scalable structure for real projects
But more importantly:
You stop thinking about “where should this go?” every time you write code.
The mistake most devs make
They either:
Overcomplicate architecture early
or
Put everything in one project until it breaks
This sits in the middle:
Simple enough to start fast, structured enough to scale.
I packaged this into a starter setup
After rebuilding this structure across multiple projects, I turned it into a ready-to-use starter kit so I don’t repeat the setup every time.
If you want a clean .NET foundation you can just clone and build on:
https://yaman95.gumroad.com/l/clean-core-dot-net-starter-kit
Top comments (0)