Layered Architecture vs Feature Folders
Source: Dev.to
Introduction
Choosing between Layered Architecture and Feature Folders in .NET is often presented as a simple folder‑structure decision. In practice it’s a deeper architectural choice that impacts code‑base growth, delivery speed, and technical debt.
I have built and maintained production systems using both approaches, experiencing the safety of classic layering and the friction it can introduce when speed matters, as well as the flow of Feature Folders and the chaos that can appear without discipline. This post is based on real‑world observations of what broke, what slowed teams down, and what ultimately worked better.
Layered (or Onion) Architecture
Most .NET developers encounter a layered structure early in their careers: Core, Infrastructure, Application, and Web/API. It’s easy to explain, diagram, and widely accepted as a “safe” architectural choice.
On paper, layered architecture satisfies Clean Architecture principles:
- Dependencies point inward.
- Business logic is isolated.
- Infrastructure concerns are abstracted away.
Typical pain points
- Multiple layer changes: Adding a new feature often requires touching several layers, even for small changes.
- Cross‑layer leakage: Infrastructure concerns creep into application code.
- Onboarding difficulty: New developers struggle to locate where logic belongs.
Example: Adding a CreateOrder endpoint
// Web layer
/Web/API/Controllers/OrderController.cs
// Application layer
/Application/Commands/CreateOrderCommand.cs
/Application/Handlers/CreateOrderHandler.cs
// Core/Domain
/Core/Domain/Order.cs
// Infrastructure
/Infrastructure/Repositories/OrderRepository.cs
/Infrastructure/Mapping/OrderProfile.csThe approach is safe and explicit, but verbose and slow, especially for small teams.
Feature Folders
Feature Folders organize code by business capability rather than technical layer. All files related to a feature live together, making it easier to understand and modify behavior in one place.
Benefits observed
- Faster, more focused feature development.
- Simpler refactoring for isolated features.
- Reduced context‑switching and easier code reviews.
Example folder layout
/Features
/Orders
OrderController.cs
CreateOrderHandler.cs
OrderValidator.cs
OrderRepository.cs
OrderDto.csThis structure minimizes ceremony and debates about file placement, allowing teams to concentrate on business problems.
Trade‑offs
| Aspect | Layered Architecture | Feature Folders |
|---|---|---|
| Pros | Strong boundaries, easier enforcement of SOLID, suitable for large teams | Faster iteration, easier onboarding, aligns with business concepts |
| Cons | Slower delivery, more boilerplate, higher cognitive load for everyday changes | Risk of duplicated logic, need for clear conventions |
What actually broke?
On one project we started with a layered approach because it was considered best practice. After six months:
- Onboarding was painful.
- Feature delivery slowed dramatically.
Refactoring toward Feature Folders restored momentum, but only after introducing rules for shared logic and avoiding uncontrolled sprawl.
Choosing the right approach
- Small teams / fast‑moving products → Feature Folders tend to win.
- Platforms with heavy cross‑cutting concerns → Layered architecture may be more appropriate.
- Hybrid solutions → Combining both styles often works best, using layers for shared infrastructure while keeping feature‑specific code in feature folders.
Practical recommendations
- Try Feature Folders for your next vertical slice, even inside a layered project, and observe the impact on speed and clarity.
- Avoid premature abstraction: let duplication surface naturally before extracting shared components.
- Never create a generic “Common” folder without clear ownership and purpose.
Architecture should enable teams, not constrain them.