Architectural Styles

An architectural style is a named collection of design decisions and constraints that gives a system its fundamental structural character. Choosing an architectural style is one of the most consequential decisions in software design — it shapes how teams are organized, how code is structured, how systems are deployed, and how they evolve over time.

Each style comes with trade-offs. There is no universally correct architecture. The right choice depends on the problem being solved, the team building it, and the constraints of the environment.

Styles Covered

Layered Architecture

Separate responsibilities into horizontal layers. The most common starting point for many applications.

Hexagonal Architecture

Isolate the domain from infrastructure using ports and adapters. Also known as ports & adapters architecture.

Modular Monolith

A single deployable unit with well-defined internal module boundaries. A pragmatic middle ground.

Microservices

Independently deployable services organized around business capabilities with decentralized data ownership.

Event-Driven Architecture

Connect components through events for loose coupling, asynchronous processing, and temporal decoupling.

Comparison

Style Main Idea Good Fit Main Risk
Layered Horizontal separation of concerns CRUD applications, small teams, well-understood domains Layers become pass-through; logic scatters across layers
Hexagonal Domain isolation via ports and adapters Complex domains, applications with many integrations Over-engineering for simple applications; indirection overhead
Modular Monolith One deployable with strong module boundaries Growing teams that need structure without distribution Module boundaries erode over time without discipline
Microservices Independent services around business capabilities Large organizations, independent team deployment Distributed system complexity; operational overhead
Event-Driven Components communicate through events Asynchronous workflows, system integration, event sourcing Debugging difficulty; eventual consistency challenges

These styles are not mutually exclusive. Many real systems combine elements from multiple styles — for example, a microservices system where each service uses hexagonal architecture internally.