Layered (N-Tier)

Organizes the application into layers with unidirectional dependencies: Presentation → Application → Domain → Infrastructure.

Context

The default organization for most business applications. Each layer has a clear responsibility.

Problem

Without rules, everything ends up in the controller or a God Service.

Solution

Layers with dependencies only downwards:

Presentation → Application → Domain → Infrastructure

In Clean Architecture, the direction is inverted: Infrastructure depends on the Domain (Dependency Inversion).

#Example in C# — projects

CSHARP

Solution/
├── MyApp.Web              ← Controllers / Razor / Minimal API
├── MyApp.Application      ← Use cases (Commands, Queries)
├── MyApp.Domain           ← Entities, value objects, rules
└── MyApp.Infrastructure   ← EF Core, HTTP clients, repositories

// Domain
public class Order { public Guid Id { get; } public void Confirm() { /* invariants */ } }

// Application
public record ConfirmOrderCommand(Guid Id);
public class ConfirmOrderHandler { /* orchestrates domain + repository */ }

// Infrastructure
public class EfOrderRepository : IOrderRepository { /* persistence */ }

// Web
[ApiController] public class OrdersController : ControllerBase { /* delegates to Application */ }

#The underlying problem

In classic Layered, dependencies go all the way down to the data layer: the domain ends up depending on infrastructure. That is the motivation for Hexagonal, Onion and Clean, which reverse that direction. If your business logic is simple, Layered is enough and perfectly valid; see the comparison.

When NOT to use it

For small microservices: a layer might be superfluous.
When the team abuses "anemic domain": layers become flat CRUD.

#architecture #layered