Unlocking Pattern Languages: From Design Patterns to Architecture

What a pattern is

Patterns are concise summaries of proven, reusable solutions. They serve as a shared vocabulary, are applied only when a matching problem appears, fit specific contexts, reflect a broader knowledge base, require deliberate practice, and exist in large numbers.

Summarize habitual approaches – a conceptual glossary of common practices.

Solution when needed – follow the hammer principle: use a pattern only when the problem matches.

Context‑specific – most patterns are irrelevant to a given system; only a few apply.

Knowledge‑system indicator – the breadth of patterns you know shows exposure, not raw coding skill.

Require intentional practice – misunderstandings are normal and improve with use.

Numerous families – from classic GoF design patterns to container, architecture, and domain‑specific patterns.

Pattern families beyond classic design patterns

Container design patterns – e.g., Sidecar, Adapter, Ambassador for cloud‑native scenarios.

Architecture patterns – reusable solutions for common architectural problems; includes micro‑services, event‑driven architectures, layered architectures, etc.

Finding patterns in a new domain

When entering an unfamiliar domain, engineers search for existing patterns to guide system design, allowing rapid composition of proven structures. The main difficulty is identifying the appropriate pattern and understanding relationships among patterns.

Pattern classification: catalog, collection, repository

Patterns rarely stand alone; they are combined into pattern collections . POSA 5 describes several ways to organise collections:

Ad‑hoc organization.

Hierarchical by abstraction, granularity, and scale.

Domain‑based (telecom, finance, e‑commerce, etc.).

Partition‑based (layers, tiers, components, packages).

Intent‑based (GoF’s 23 design patterns, DDD, etc.).

Design‑pattern organization (GoF)

Creational : Singleton, Abstract Factory, Builder, Factory Method, Prototype.

Structural : Adapter, Bridge, Decorator, Composite, Facade, Flyweight, Proxy.

Behavioral : Template Method, Command, Iterator, Observer, Mediator, Memento, Interpreter, State, Strategy, Chain of Responsibility, Visitor.

Categories are defined by purpose (what work they accomplish) and scope (class‑level vs. object‑level).

Domain‑Driven Design (DDD) organization

Applying the domain model – model‑knowledge‑extraction patterns.

Building blocks of model‑driven design – model‑design patterns.

Deepening understanding through refactoring – model‑optimization patterns.

Strategic design – model‑boundary definition patterns (bounded contexts, context maps, core vs. generic domains, large‑scale structures such as evolving order).

Pattern languages

A pattern language tightly couples to a specific domain and provides systematic guidance: it defines the main problems, their ordering, alternative solutions, dependency handling, and efficient resolution of individual problems within a surrounding context.

Distributed‑computing pattern language (POSA 4)

POSA 4, Pattern‑Based Software Architecture: A Pattern Language for Distributed Computing , presents a diagram where each circle denotes a problem domain containing related patterns such as MVC, layered architecture, PAC, micro‑kernel, etc. The language shows how to compose these patterns to move “from mud to structure”.

For example, the “From Mud to Structure” domain includes MVC, layered, PAC, and micro‑kernel patterns; additional sub‑domains (e.g., database access) contribute further patterns to complete the design.

Microservice pattern language (Chris Richardson)

Richardson’s “Microservice Architecture Design Patterns” organises patterns across multiple layers (service decomposition, API design, data management, resilience, deployment, etc.) and visualises their inter‑relations. Although the diagram lists relationships without detailed descriptions, it still aids systematic microservice design.

Pattern‑of‑patterns (meta‑patterns)

Meta‑patterns describe how to organise or discover other patterns. Common meta‑patterns include:

Contract – inputs/outputs, APIs.

Separation – isolating change, clarifying responsibilities.

Constraint – functional and non‑functional requirements, performance.

Encapsulation – interface encapsulation.

Collaboration – collaboration styles.

Elemental Design Patterns (EDP)

EDP extracts fundamental object‑oriented concepts from existing design patterns. The four core concepts are:

Object creation.

Object retrieval.

Inheritance.

Abstract interfaces.

Method calls can be abstracted into four actions: recursion, delegation, redirection, and aggregation. These form the building blocks for higher‑level design patterns.

References

"Elemental Patterns"

"Design Patterns: Elements of Reusable Object‑Oriented Software"

POSA 4 – "Pattern‑Based Software Architecture, Volume 4: A Pattern Language for Distributed Computing"

POSA 5 – "Pattern‑Based Software Architecture, Volume 5: Patterns and Pattern Languages"

"Domain‑Driven Design: Tackling Complexity in the Heart of Software"

GitHub repository:

https://github.com/phodal/pattern-languages