architecture-paradigm-layered git:20260921.ad5ceb4A

Immutable. This exact content never changes and is served at /api/v1/blob/cd568cd0a7308ecc.

---
name: architecture-paradigm-layered
description: Applies layered n-tier architecture with enforced boundaries. Use when designing moderate systems needing clear presentation, domain, and persistence layers.
alwaysApply: false
category: architectural-pattern
tags:
- architecture
- layered
- n-tier
- separation-of-concerns
- monolith
dependencies: []
tools: []
usage_patterns:
- paradigm-implementation
- legacy-system-modernization
- team-structure-alignment
- compliance-requirements
complexity: low
model_hint: fast
estimated_tokens: 700
---

# The Layered (N-Tier) Architecture Paradigm

## When to Employ This Paradigm
- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.
- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).
- When the deployment artifact remains a monolith, but code clarity and separation are degrading.

## When NOT To Use This Paradigm
- When high scalability demands require independent scaling of components
- When multiple teams need independent deployment cycles
- When complex business logic requires frequent cross-layer communication
- When microservices architecture is already planned or in place
- When real-time processing requirements make layered communication too slow

## Adoption Steps
1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.
2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any "upward" dependencies or imports.
3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.
4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.
5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating "shortcut" dependencies that violate the layering rules.

## Key Deliverables
- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.
- A formal dependency diagram stored with the project documentation.
- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.

## Technology Guidance

**Layer Implementation Patterns**:
- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)
- **Application Layer**: Service classes, Application services, Use case orchestrators
- **Domain Layer**: Business entities, Domain services, Business rules validation
- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)

**Architecture Enforcement Tools**:
- **Java**: ArchUnit for dependency rule testing
- **JavaScript/TypeScript**: ESLint rules with dependency tracking
- **C#**: NDepend for architectural analysis
- **Python**: Custom decorators and import analysis tools

**Common Layer Stacks**:
- **3-Layer**: Presentation → Business Logic → Data Access
- **4-Layer**: Presentation → Application → Domain → Infrastructure
- **5-Layer**: UI → Controller → Service → Domain → Persistence

## Real-World Examples

**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.

**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.

**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.

## Risks & Mitigations
- **Excessive Rigidity and Latency**:
  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive "pass-through" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.
- **"Leaky" Layers**:
  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.

## Concrete Components

Vocabulary for the tools and abstractions an implementation of this
paradigm tends to carry. Not dependencies, and not ``tools:`` frontmatter.

- ``dependency-validator``: fails the build when a layer imports above its allowed depth
- ``layer-enforcer``: static-analysis gate that checks namespaces match layer rules
- ``architecture-compliance-checker``: diffs the implemented layer graph against the documented one

## Exit Criteria

- [ ] An ADR captures the chosen layer stack (3-layer, 4-layer, or 5-layer), responsibilities
  per layer, allowed dependency direction, and the policy for cross-layer exceptions.
- [ ] A formal dependency diagram is committed to project documentation and matches the ADR's
  stated layer boundaries.
- [ ] Automated architectural checks (ArchUnit, dep-cruise, or equivalent) are wired into CI
  and fail the build on any upward dependency.
- [ ] Cross-cutting concerns (logging, auth, validation) are implemented once as middleware or
  policy and are not duplicated across layer implementations.