What are common architectural patterns (layered, hexagonal, etc.)?

Question

Accepted Answer

Beyond object-level design patterns, **architectural patterns** define the high-level structure of applications — like **layered**, **hexagonal (ports and adapters)**, **clean architecture**, and **event-driven**. They organize entire systems for maintainability, testability, and flexibility.

## Layered (n-tier) architecture

```text
LAYERED → organize the app into horizontal LAYERS, each with a responsibility:
  PRESENTATION (UI) → APPLICATION/business logic → DATA ACCESS → DATABASE
  → each layer depends only on the layer below; clear separation
  ✓ simple, common, organized  ✗ can become rigid; layers can leak; less flexible
```

## Hexagonal / Clean architecture

```text
HEXAGONAL (ports & adapters) / CLEAN architecture → the core business logic is ISOLATED
from external concerns (UI, database, frameworks):
  → the DOMAIN/core depends on NOTHING external; external things (DB, UI, APIs) plug in
    via interfaces ("ports") and "adapters"
  → dependencies point INWARD (toward the domain) → the core is independent and testable
  ✓ highly testable, flexible (swap DB/UI/frameworks), domain-focused
  ✗ more complexity/structure (justified for complex domains)
```

## Other architectural patterns

```text
EVENT-DRIVEN → components communicate via events (decoupled, scalable, reactive)
MICROSERVICES → independent services (covered in system design)
MVC/MVVM → UI architecture (covered separately)
CQRS / EVENT SOURCING → separate read/write; events as the source of truth
PIPELINE / pipes-and-filters → data flows through processing stages
→ choose based on the system's complexity, domain, and needs
```

## Why it matters

Understanding common architectural patterns is valuable senior-level knowledge because they define **how entire applications are structured**, significantly affecting maintainability and flexibility, so it's important for designing well-structured systems.

Architectural patterns operate at a higher level than object-level design patterns, organizing entire systems.

Understanding **layered architecture** (organizing into horizontal layers — presentation, business logic, data access — each depending on the one below, providing simple, common organization but potential rigidity) is foundational, as it's the most common application structure.

Understanding **hexagonal/clean architecture** is particularly valuable: isolating the core business logic from external concerns (UI, database, frameworks) so the domain depends on nothing external while external things plug in via ports and adapters, with **dependencies pointing inward toward the domain** — making the core independent, highly testable, and flexible (able to swap databases, UIs, and frameworks).

This domain-centric approach is influential in modern architecture for complex domains, though it adds structure that must be justified.

Understanding **other architectural patterns** — event-driven (decoupled, reactive), microservices, MVC/MVVM, **CQRS/event sourcing** (separating reads/writes, events as the source of truth), and pipeline/pipes-and-filters — broadens awareness of how systems can be structured.

Understanding these patterns and **choosing based on the system's complexity, domain, and needs** reflects the architectural judgment to structure applications appropriately.

Architectural patterns significantly affect a system's maintainability, testability, and flexibility — choosing and applying them well is a key senior skill.

Since architectural patterns define how entire applications are structured (significantly affecting maintainability, testability, and flexibility) and understanding the options (layered, hexagonal/clean, event-driven, CQRS) and choosing appropriately is important for designing well-structured systems, understanding common architectural patterns is valuable senior-level knowledge — important for structuring entire applications well (especially the influential clean/hexagonal approach for testable, domain-focused systems), reflecting the architectural judgment expected of senior developers who design system structure, and complementing object-level patterns with higher-level organization.