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 */ }

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