Design patterns — index

Pattern thinking means naming recurring forces (change, scale, integration) and matching proven structures — without using the catalog as a mandatory checklist. Prefer simple modules until duplication proves the force.

Guide · Updated · Source

Cross-reference: Parent summaries for GoF and enterprise patterns: Software engineering body of knowledge § 3. Design patterns.


Pattern categories (overview)

Pattern category lanes

Two parallel tracks for matching named forces to proven structures without treating the catalog as mandatory.

  1. Pattern categories (overview)Frames how pattern families coordinate on this index page.
  2. Lane AThe forward path from force identification toward a shared design outcome.
  3. handoffPasses a resolved pattern concern to the next selection step.
  4. shared outcomeThe bounded structure both lanes converge on after pattern selection.
  5. Lane BThe inspect-and-adapt path for revising pattern choice as forces clarify.
  6. inspect / adaptReviews applied patterns against duplication and integration pressures.
  7. feedbackReturns selection lessons to refine the next pattern pass.
  8. Note: single-processScopes in-process collaboration patterns to one runtime boundary.

GoF addresses single-process collaboration; EIP addresses cross-service messaging and evolution.


Selection guidance

Situation Start here Escalate when
Variable object creation GoF creational Many product families need registries
Compose or wrap types GoF structural Adapters absorb domain rules
Vary algorithms or notifications GoF behavioral Cross-service sagas dominate
Decouple services / absorb bursts Enterprise integration Ordering, idempotency, schema contracts
Shared-memory parallelism Concurrency patterns (planned) Locks/races drive the design

Guides

Guide Focus See
GoF design patterns 23 patterns, selection flowchart, modern relevance
Enterprise integration Channels, routing, transformation, sagas, platforms
Concurrency patterns (planned) Active object, monitor, fork-join, pipeline SOFTWARE-ENGINEERING.md §3

Keep project-specific engineering standards in docs/development/ and architecture decisions in docs/adr/, not in this file.