architecture-paradigm-layered

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

Table of Contents

• When to Employ This Paradigm
• When NOT to Use This Paradigm
• Adoption Steps
• Key Deliverables
• Technology Guidance
• Risks & Mitigations

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.