Skip to content

Styles and Techniques

This catalog distinguishes two levels of pattern: Styles and Techniques. The distinction exists because patterns have natural parent-child relationships, and flattening them into siblings creates confusion — a reader looking for "how to guarantee exactly-once delivery" should find it nested under the style where it applies, not listed alongside the broad architectural shapes it supports.

Defining Styles and Techniques

What makes a pattern a Style?

A Style describes the broad shape of a system — how it is divided, how its components communicate, and what organisational and operational constraints it implies. A useful test: "Could this pattern be described in one sentence as 'the way the system is organised'?" If yes, it is a Style.

Examples: Event-Driven Architecture (the system is organised around a durable event log that decouples producers from consumers), Microservices (the system is organised as independently deployable services with separate data stores), Modular Monolith (the system is organised as strongly-bounded modules within a single deployable unit).

What makes a pattern a Technique?

A Technique is a focused mechanism that solves one specific problem within or across Styles. A useful test: "Could this pattern be described as 'the specific mechanism used to solve X'?" If yes, it is a Technique.

Examples: Transactional Outbox + CDC (the specific mechanism used to guarantee that a database write and a message publish are atomic), Schema Registry (the specific mechanism used to enforce backward-compatible schema evolution across producers and consumers), Circuit Breaker (the specific mechanism used to prevent cascading failures when a downstream service is degraded).

The difference in scope is the key signal: Styles span an entire system's architecture; Techniques address one well-defined problem within it.

Choosing a primary parent Style

Every Technique has exactly one primary parent Style. The parent is:

  • The Style where the Technique is most heavily used in practice
  • The Style where the Technique is most thoroughly documented in published literature
  • The Style where covering the Technique in full depth makes most pedagogical sense for a reader learning that Style

When a Technique is used by multiple Styles to roughly equal degrees, the tie-breaker is the Style where the Technique was historically introduced or where it is most strongly associated in industry literature.

Worked example: The Transactional Outbox + CDC Technique is used by Event-Driven Architecture, CQRS with CDC-Driven Read Models, and the Saga Pattern. Its primary parent is Event-Driven Architecture — Outbox + CDC was widely documented in the context of EDA, the majority of practitioner writing about it appears in EDA literature, and the motivating problem (reliable event emission from a producer service) is most naturally understood within an EDA context. CQRS and Saga reference the Technique but do not need to re-explain it.

Handling Techniques used by multiple Styles

A Technique is documented once and referenced everywhere it applies. The rules:

  • The Technique page lists its primary parent in the Quick Facts block under a Parent style field.
  • The Technique page lists an Also used by field naming all other Styles that rely on it.
  • Other Styles that use the Technique mention it in their Section 11 (Related patterns) with a one-line summary and a link to the Technique's primary page. They do not duplicate the Technique's content.
  • Pattern pages that reference a Technique they do not own use this form: "Technique name — one-line description of why it applies here."

This keeps the catalog DRY: a change to the Technique's content (updated tooling, revised guidance) is made in one place and propagates by reference everywhere else.

Boundary cases

"Is this pattern a Style or a Technique?"

When a pattern feels in-between, apply this heuristic: does it have its own architectural shape and substantial sub-patterns of its own? If yes, treat it as a Style. If it is a focused mechanism solving one specific problem, it is a Technique.

CQRS and the Saga Pattern are borderline cases. Both are often described as "patterns" in the literature, but each has its own architectural shape (CQRS: separated read and write models; Saga: a state machine of compensating transactions) and each has meaningful sub-patterns beneath it (CQRS → projection types, event sourcing integration; Saga → orchestrated vs choreographed, compensation maps). Both are treated as Styles in this catalog.

"What if a Technique has no clear primary parent?"

Pick the most common context in which the Technique is taught or encountered, and add a note on the Technique page explaining the choice. If the Technique is genuinely orthogonal — equally fundamental to every Style with no natural home — it may belong as a cross-cutting pattern. Cross-cutting patterns are rare; treat this as an edge case requiring a deliberate decision, not a default.

"Can a Style be nested under another Style?"

No. Styles are always top-level entries within a category. Nesting Styles would imply a hierarchy of architectural shapes that does not map to how systems are designed or how teams select patterns. If two Styles feel hierarchical, one of them is probably a Technique.

"Can a Technique have its own child Techniques?"

This is discouraged. Keep the hierarchy two levels deep: Style → Technique. If a Technique appears to need child entries, reconsider whether it should be promoted to a Style. Deep hierarchies increase the maintenance burden and make the catalog harder to navigate.