⌘ The Architecture Reference

Sty fundamentals · Guide · Start here

Reading an Architecture Style

What an architecture style is, how it differs from a pattern, and how to read each style's characteristics scorecard before you commit to one.

Sty fundamentals Start here ⏱ 4 min read Complete

🧭 Analogy

Choosing an architecture style is like choosing a vehicle. A sports car, a minivan, and a cargo truck are all “correct” — for different jobs. None is best at everything: the sports car trades cargo space for speed, the truck trades agility for payload. An architecture style is the same kind of named bundle of strengths and sacrifices.

Style, pattern, design pattern

These three words are often used interchangeably, but Software Architecture Patterns keeps them in a strict hierarchy:

  • Architecture style — the macro structure of a system: how its code is organized into deployment units and how those units interact (e.g., layered, microservices, event-driven).
  • Architecture pattern — a reusable structural building block used inside a style to solve a specific problem (e.g., CQRS, Command Query Responsibility Segregation, which separates read and write models). A pattern can appear in any style.
  • Design pattern — a code-level construct (e.g., Builder) that shapes source code.

Styles are composed of patterns, which are composed of design patterns. CQRS, for instance, can be applied inside a microservices style and implemented with Builder objects.

graph TD
S["Architecture style<br/>(macro structure, e.g. event-driven)"] --> P["Architecture pattern<br/>(building block, e.g. CQRS)"]
P --> D["Design pattern<br/>(code construct, e.g. Builder)"]

The characteristics scorecard

Every style is rated against a common set of architecture characteristics — the non-functional “-ilities.” The book scores each on a 1-to-5 dot scale (1 = poorly supported, 5 = excellently supported) and rates cost separately on a 1-to-5 dollar scale (one dollar = cheapest). The characteristics that matter most across styles are:

  • Partitioning — technical or domain (see Technical vs domain partitioning).
  • Deployability, elasticity, scalability — the operational “superpowers” of distributed styles.
  • Performance, simplicity, testability — often where monoliths win.
  • Fault tolerance and cost — usually inversely related to each other.

Read the scorecard, not the hype

A style’s name tells you almost nothing. “Microservices” sounds modern, but its scorecard shows the highest cost and weakest performance among distributed styles. The scorecard is how you separate fashion from fit.

No structure is the worst structure

Skipping this analysis altogether produces the big ball of mud: a tightly coupled, brittle, spaghetti-code system with no clear vision. The danger is not that it is ugly — it is that it has no predictable characteristics. You cannot say whether it scales, performs, or can be changed safely, because nothing about it was decided on purpose.

Hybrids are normal — but learn the parts first

Real systems frequently combine styles: event-driven microservices, space-based microservices, event-driven microkernel. That is healthy. The pitfall is reaching for a hybrid before you understand each constituent style’s individual strengths and weaknesses — you just multiply the problems you do not understand.

How to read each style page

Each style in this track follows the same template:

graph LR
T["1. Topology<br/>components + flow"] --> C["2. Components<br/>named parts"]
C --> S["3. Characteristics<br/>scorecard"]
S --> U["4. When to use<br/>/ avoid"]
  1. Topology — a diagram of the components and how requests flow.
  2. Components — the named parts and what each does.
  3. Characteristics — the scorecard, with the standout strengths and weaknesses.
  4. When to use / when to avoid — the trade-off guidance.

Once you can read one scorecard, you can compare them all in Comparing the styles and apply the decision process in Choosing an architecture style.

See also

When to use it — and when not

✅ Reach for it when

  • You are about to pick a structure for a new system and want a shared vocabulary for the trade-offs.
  • You inherited a system and need to name its style to reason about what it can and cannot do.
  • You want to combine styles into a hybrid and need to understand each one first.

⛔ Think twice when

  • You only need a code-level construct — that is a design pattern, not an architecture style.
  • The system has no discernible structure at all — fix the big ball of mud before classifying it.
sty-fundamentalsTechnical vs Domain Partitioning

The orthogonal axis that decides whether your code is organized by technical layer or by business domain — and why it must match your teams and your changes.

sty-choosingComparing the Styles

The consolidated scorecard — every style rated across partitioning, cost, simplicity, scalability, fault tolerance, performance, and more — and how to read it for trade-offs.

sty-choosingChoosing an Architecture Style

The decision process — monolith vs distributed via the quantum, where data lives, sync vs async — plus worked monolith and distributed case studies.

Check your understanding

Score: 0 / 4

1. What is the difference between an architecture style and an architecture pattern?

A style (e.g., event-driven) describes the system's overall shape; a pattern (e.g., CQRS) is a structural building block that can live inside many styles, which in turn use design patterns like Builder.

2. What does it mean that 'every style is a set of trade-offs'?

No style maximizes every characteristic. High scalability and fault tolerance, for example, almost always cost simplicity and money.

3. What is the 'big ball of mud' the book warns against?

Coding without a deliberate style produces a big ball of mud: you cannot answer whether it scales, performs, or can change, because it has no known characteristics.

4. On the book's scorecard, what does a five-dot rating for a characteristic mean?

Each characteristic is scored 1 (poorly supported) to 5 (excellently supported); cost uses a separate 1-to-5 dollar scale where one dollar is cheapest.

Comments

Sign in with GitHub to join the discussion.