All patterns
Foundational
Layered (N-Tier)
Separate concerns into horizontal layers
Organizes code into presentation, application, domain, and infrastructure layers. Each layer depends only on layers below it, improving maintainability without distributing the system.
Startup scalelow complexity
Architecture diagram
High-level component relationships
Key components
Presentation
Controllers, REST handlers, GraphQL resolvers
Application
Use cases, DTO mapping, orchestration
Domain
Entities, value objects, domain services
Infrastructure
Repositories, messaging, third-party adapters
Data flow
- Request enters presentation and maps to an application command
- Application layer coordinates domain objects
- Infrastructure persists or fetches data via repositories
- Response flows back up without skipping layers
Pros
- Clear separation of concerns and testability
- Domain logic stays independent of frameworks
- Easier onboarding — structure is predictable
- Works well inside monoliths and modular monoliths
Cons
- Can become anemic if domain layer is bypassed
- Extra boilerplate for simple CRUD apps
- Wrong boundaries (by technical layer vs business capability) hurt agility
When to use
- Medium-complexity business applications
- Teams practicing DDD or clean architecture
- When you need maintainability without microservices overhead
When to avoid
- Simple CRUD with no complex domain rules
- Event-heavy systems where vertical slices fit better
Real-world examples
- Enterprise ERP modules
- Banking cores
- Clean architecture .NET apps
Related technologies
Hexagonal architectureDDDRepository pattern