What is a pattern, and what isn't?

pattern   pattern language   architecting   decision making  

---

---

Software engineers draw on many kinds of reusable knowledge, including principles, practices, techniques, patterns, designs, methods, rules, reference architectures, and implementation approaches. Lots of people write about patterns, myself included. I’ve noticed, however, that like many concepts in software engineering, the concept of a pattern has suffered from semantic diffusion. There’s a tendency to label many different kinds of reusable knowledge as “patterns”, even when they don’t meet the definition, and to call any collection of them a pattern language.

This bothers me for a few reasons. I’ve been a fan of patterns and pattern languages since the Gang of Four’s Design Patterns book popularized them in the software community in the mid 90s, for the reasons I describe below. I like Domain-Driven Design, which is all about precise terminology. And as an author, I try to use words carefully.

In this article, I define a pattern and a pattern language, and describe what distinguishes them from other kinds of reusable knowledge. I then explain why patterns are valuable and what is lost when the terms are used loosely. After that, I compare four forms for writing patterns, using the Saga pattern as the example. I end with advice for authors and readers. Let’s start with the definition of a pattern.

What is a pattern

The common definition of a pattern is

A recurring solution to a common problem within a specific context.

The context describes the situation in which the problem arises. The problem has forces, which are the considerations that make it difficult to solve and that any solution must balance. The problem is stated explicitly, as a question or a difficulty, and the solution is specific enough that a reader knows what to do to apply it. Christopher Alexander called such a pattern generative: “Each pattern is a rule which describes what you have to do to generate the entity which it defines.” A pattern that only describes what a good solution looks like, without saying how to produce it, is descriptive rather than generative.

I like to extend this definition in two ways. First, a pattern describes the consequences of applying the solution: its benefits, its drawbacks, and the issues, which are the sub-problems that you must solve when you apply it. Second, a pattern describes its related patterns:

• Alternatives - other patterns that solve the same problem in a different way
• Successor patterns - patterns that solve the issues that arise after applying this pattern
• Predecessor patterns - patterns that create the problem that this pattern solves
• Generalizations - patterns that are a more general solution to this pattern’s problem
• Specializations - patterns that are a more specific form of this pattern

The microservice architecture pattern language has examples of each kind of relationship. The Database per Service pattern is a predecessor of the Saga pattern, because giving each service its own database creates the problem of maintaining data consistency across services. The Transactional Outbox and Event Sourcing patterns are successors of Saga, because they solve one of its issues: each saga step must atomically update the database and publish a message. The API Composition and CQRS patterns are alternatives, because both solve the problem of implementing a query that retrieves data from multiple services. The Service per container and Service per VM patterns are specializations of the Single service per host pattern, which is their generalization.

What is a pattern language

Alexander also introduced the concept of a pattern language. His book A Pattern Language: Towns, Buildings, Construction describes 253 patterns for designing towns and buildings, ranging from where to locate a city to how to light a room. A pattern language is a set of patterns that solve the problems within a particular domain. The patterns have rich relationships between them, of the kinds described above: alternatives, predecessors, successors, generalizations and specializations. Those rich relationships are what distinguish a pattern language from a pattern collection, which is a set of weakly related patterns, such as the patterns in the Gang of Four book. A pattern collection is useful too, but a pattern language also guides you from one pattern to the next.

Alexander also called a pattern language generative, in a related sense: each pattern tells you what to do, and the relationships tell you which pattern to apply next. Like a natural language, it “not only tells us the rules of arrangement, but shows us how to construct arrangements – as many as we want – which satisfy the rules.” Applying one pattern produces the context in which the next one applies, so following the relationships produces a whole design rather than a list of parts.

The microservice architecture pattern language is an example. It first helps you decide whether to use the microservice architecture, by describing the Monolithic architecture and Microservice architecture patterns as alternatives, along with their benefits and drawbacks. If you choose the microservice architecture, its successor patterns help you solve the problems that it creates, such as implementing transactions and queries that span services. Let’s now look at what is not a pattern.

What is not a pattern

A description that lacks one of the elements of a pattern is some other kind of knowledge. A solution that is described without its context and forces is a technique. A solution that has only been applied once is a design, because a pattern must recur. A list of good ways of working with no single problem that they solve is a set of practices. A general statement of what a good solution looks like, with no solution to a specific problem, is a principle. An instruction to do something whose problem can only be inferred from its benefits is a rule. A collection of patterns that does not describe how they relate to one another is a pattern collection rather than a pattern language.

My own writing provides an example. The original version of the GenAI-based development platform - part 4: The coding agent sandwich article called the coding agent sandwich a pattern. The coding agent sandwich is a technique, because the article describes one architecture and its rationale without the context and forces that determine when to use it. The distinction matters because of what a pattern gives its reader.

Why patterns are useful

A pattern’s context, forces, solution and consequences tell you when it applies, how it works and what it costs. That gives patterns three benefits.

First, patterns are an antidote to hype. As I described in The pattern format: an antidote to hype, most articles that advocate a technology describe its benefits and ignore its drawbacks. A pattern must describe its drawbacks and the issues that it creates, so it gives a balanced view of the solution.

Second, patterns improve decision making. As I described in #becauseItDepends Finding your inner Vulcan: unemotional decision making with pattern-style thinking, architecture discussions are often emotional and driven by personal preference or fashion. Comparing the forces and consequences of alternative patterns turns the discussion into one about trade-offs. A pattern language helps further, because the relationships between its patterns tell you which decision to make next.

Third, patterns provide a vocabulary. A pattern name such as Saga or CQRS stands for a problem, a solution and its trade-offs. A team that knows the names can discuss a design without re-explaining each of them. These benefits are what semantic diffusion puts at risk.

The cost of semantic diffusion

Semantic diffusion weakens the word. Repeated loose usage broadens the term until it loses the distinctions that made it useful. When a reusable idea is labelled a pattern but lacks a context, forces and consequences, the label promises guidance about when to use the idea and what it costs, and the description does not provide it. Once that happens often enough, a reader has no reason to expect that guidance from anything called a pattern. The same applies to a pattern language. When a collection of techniques is called a pattern language, the label promises a guided path through the decisions in a domain, and the collection provides a list. The essence of a pattern is fixed, but the way it is written down is not.

Different ways to write patterns

As Joe Yoder and Rebecca Wirfs-Brock point out in their PLoP Pattern Writing Bootcamp (PDF), patterns are written in many different forms. A form is the structure of a pattern description: the sections that it contains and the order in which they appear. Despite their differences, every form covers the essential elements of a pattern: the context, the problem and its forces, the solution, the consequences, and the related patterns. Some forms have a section for each element, and others spread an element across several sections or leave it implicit. To show how they differ, I describe the Saga pattern in each of the following forms:

• The Alexandrian form
• The Gang of Four (GoF) form
• The Pattern-Oriented Software Architecture (POSA) form
• The Microservices Patterns form

Each description is abridged, and bracketed italic text, such as [A diagram of a saga], stands in for a picture or a passage that I have not written out.

The Alexandrian form

The Alexandrian form is the one that Christopher Alexander used in A Pattern Language. Each pattern starts with a name and a picture that shows an example of the pattern. Next is a paragraph that describes the context by listing the larger patterns that this pattern helps complete. The problem is then stated as a headline in bold, followed by a discussion of the forces and the evidence for them. The solution comes next. It starts with the word “Therefore” and is stated in bold as an instruction. The pattern ends with a diagram of the solution and a paragraph that lists the smaller patterns that are needed to complete it. Alexander also marked each pattern with zero, one or two asterisks to show how confident he was in it. The Alexandrian form is mostly continuous prose with very few headings.

Here is an outline of the Saga pattern in the Alexandrian form:

Saga *

[A picture of a saga that creates an order]

…you have applied the Database per Service pattern, so each service has its own database. This pattern describes how to implement business transactions that span those services.

❖ ❖ ❖

Some business transactions must update data that is owned by several services, but a single ACID transaction cannot span those services.

[A discussion of the forces and the evidence for them. For example, an e-commerce application must ensure that a new order does not exceed the customer’s credit limit. Orders and customers are in different databases, and distributed transactions (2PC) are not an option.]

Therefore:

Implement each business transaction that spans services as a sequence of local transactions. Each local transaction updates one service’s database and publishes a message that triggers the next local transaction. If a local transaction fails, execute compensating transactions that undo the changes made by the preceding local transactions.

[A diagram of a saga]

❖ ❖ ❖

Each step of a saga must atomically update a database and publish a message. To do this, use Transactional Outbox or Event Sourcing.

The Gang of Four (GoF) form

The Gang of Four’s Design Patterns book uses a much more structured form, which is described by the Hillside Group’s Gang of Four template. Of its twelve sections, Intent, Motivation and Applicability describe the problem and its forces. The Motivation section describes a scenario that illustrates the problem. The Structure, Participants and Collaborations sections describe the solution in terms of classes and objects, because these are object-oriented design patterns.

Here are some of the sections of the Saga pattern in the GoF form:

Intent: Maintain data consistency across services by implementing a business transaction as a sequence of local transactions.

Motivation: An e-commerce application must ensure that a new order does not exceed the customer’s credit limit. Orders and customers are in different databases, so the application cannot use a single ACID transaction.

Applicability: Use the Saga pattern when a business transaction updates data that is owned by more than one service.

Structure: [A class diagram that shows the saga orchestrator, the saga participants, and the command and reply messages that they exchange]

Participants:

• Saga orchestrator (CreateOrderSaga) - tells the saga participants which local transactions to execute
• Saga participant (Customer Service) - executes a local transaction and sends back a reply

Collaborations: The saga orchestrator sends a command message to each saga participant in turn. If a saga participant replies with a failure, the saga orchestrator sends commands that execute compensating transactions.

Consequences: A saga maintains data consistency without distributed transactions. However, a developer must write compensating transactions, and must use countermeasures to deal with the lack of isolation.

The Pattern-Oriented Software Architecture (POSA) form

The first Pattern-Oriented Software Architecture book uses a form that is organized around context, problem and solution. Brad Appleton describes the elements of this form in Patterns and Software: Essential Concepts and Terminology. Of its thirteen sections, the Problem section describes the forces as well as the problem. The Example section at the start of the pattern and the Example Resolved section near the end show the pattern being applied to a single concrete example.

Here are some of the sections of the Saga pattern in the POSA form:

Example: An e-commerce application must ensure that a new order does not exceed the customer’s credit limit. Orders and customers are in different databases, which are owned by the Order Service and the Customer Service.

Context: A microservice architecture in which each service has its own database.

Problem: How to implement a business transaction that updates data owned by several services? The solution must maintain data consistency, and it cannot use distributed transactions (2PC).

Solution: Implement the business transaction as a sequence of local transactions. If a local transaction fails, execute compensating transactions that undo the changes made by the preceding local transactions.

Dynamics: [A sequence diagram that shows the messages that are exchanged when the saga approves an order and when it rejects one]

Example Resolved: The Order Service creates an Order in a PENDING state and sends a Reserve Credit command to the Customer Service. The Customer Service attempts to reserve credit and replies with the outcome. The Order Service then approves or rejects the Order.

Variants: Choreography-based sagas and orchestration-based sagas.

The Microservices Patterns form

The patterns on this website use a form that is close to what Brad Appleton calls the canonical form in Patterns and Software: Essential Concepts and Terminology. Its eight sections include Resulting context, which describes the consequences of applying the pattern in three subsections: Benefits, Drawbacks and Issues. The Related patterns section describes the pattern’s alternatives, predecessors and successors. The Saga pattern on this website is written in this form. Whichever form you use, the first question is whether what you are writing is a pattern at all.

Advice for authors

Before you call something a pattern, check that:

• it states the problem
• it describes the context, the forces and the consequences
• the solution is generative: it describes how to construct the solution, not only what the solution looks like
• it has been applied more than once

If it does not, you have two options. You can call it what it is: a technique, a design, a practice, a principle or a rule. Or, if it is a recurring solution, you can expand the description to include the missing elements, so that it is a pattern. Writing it up in one of the forms described above is the easiest way to do that, because the form’s sections prompt you for each element.

Before you call a collection a pattern language, make sure that each member is a pattern and that there are rich relationships between them. If those rich relationships do not exist, either add them, or call it a pattern collection.

Advice for readers

When something is called a pattern, look for the problem statement, the forces and the consequences. If the problem is missing, work out what the solution is for before deciding whether you have that problem. If the forces and the consequences are missing, you are reading something other than a pattern, and you must work out for yourself when it applies and what it costs.

When a set of patterns is called a pattern language, look for the rich relationships between them. If those relationships are missing, you are reading a pattern collection.

Summary

The key idea of this article is that a pattern is more than a named solution. It is a recurring solution to a problem in a context, together with the forces, the consequences and the related patterns. That structure is what makes patterns useful. It tells you when a solution applies, what it costs, and which patterns to look at next. A pattern language is a collection of patterns whose relationships guide you from one decision to the next. Calling a technique or a design a pattern, or a collection of them a pattern language, weakens the words. Eventually a reader has no reason to expect that structure from anything that carries the label. So check for those elements before you use the words, and look for them when you read them.

Need help with modernizing your architecture?

I help organizations modernize their architecture to enable fast flow and GenAI-powered software delivery. If you’re planning or struggling with a modernization effort, I can help.

Learn more about my modernization and architecture advisory work →