Introduction

The concept of a Pattern Language was proposed by Christopher Alexander, an architect and design theorist active in the second half of the 20th century, in a sequence of three books. This influenced a design patterns movement within Software Development, kick-started by the book Design Patterns: Elements of Reusable Object-Oriented Software (1994) (colloquially known as the "Gang of Four" book). This book has had an out-sized impact on Software Development practice and discourse, and has shaped the general understanding of what design patterns are and how they apply to developing, deploying, and maintaining software.

What is a Pattern?

As with any concept, such as Design Patterns, that has been around for a long while, interpreted and re-interpreted by many groups and individuals over the years, it is instructive to start by stating what Design Patterns are not:

  • Design patterns are not mainly about objects and classes
  • "Design pattern" does not refer specifically to one of the patterns in the book
  • A Design Pattern is not something you only use in specific cases (with the rest of what a programmer writes being just "regular code" )
  • Design Patterns are do not have a set size range
  • A Design Pattern is not something that is rigid and set in stone, such that every implementation must follow every detail of the pattern to the letter
  • The description of a Design Pattern does not have to follow the formal template used in the Design Pattern book

So, if Design Patterns are not any of these things, then what are they?

Patterns can exist at any level of system design or development, in any flavor of programming language or approach. There are many patterns beyond those described in any single book. Indeed, new patterns will naturally arise all the time as new problems are approached by developers in new and inventive ways. If you look closely, you will find patterns exist implicitly in almost all the code you write or systems you build. Furthermore, patterns are often fractal, meaning most patterns form a combination of smaller patterns, and are themselves components in bigger patterns. Finally, and perhaps most importantly, Design Patterns form a language that constantly evolves to adapt to a changing world.

A Pattern Language

In terms of the source material, the most commonly referenced of Alexander's books is A Pattern Language (1977), which describes a concrete set of patterns which Alexander and his collaborators found to be a useful and sufficient language for building. However, to truly understand the intent and scope of design patterns we have to read The Timeless Way of Building (1979), which was published a few years later, but which Alexander saw as the predecessor of A Pattern Language, setting the stage and explaining his philosophy and intent. This is the source material that we go back to for our conceptualization of A Pattern Language.

It is important to note that a Pattern Language is a language, an idiom, which shares many characteristics with natural language. It is shared by a group of people who use it daily as a means of communication. It forms a basis for developing and expressing ideas. Different, but adjacent, groups will often speak similar, overlapping but distinct pattern languages, and each person will use that language in their own unique way.

Much like natural languages, a pattern language may evolve over time as it grows and changes and meanings shift. A word's meaning is its usage (this is descriptivist, rather than prescriptivist, view of language with which we agree), and so too with a pattern: how it is used determines what it means beyond any prescribed definition.

The pattern language described in the Tea Garden is the language spoken by the Gaiwan team, our common vernacular. The patterns in our pattern language can extend from the very small (tiny programming language idioms) to the very large (deployment and maintenance of entire systems), and even beyond the purely technical to organizational and social patterns. We describe patterns wherever we see them and find them useful and hope that, by sharing them here, others can benefit from the growth and evolution of our pattern language.

The Pattern of Patterns

When it is time to start a new project, or a major new feature of an existing project, there are typically many technical decisions that need to be made. How you approach these decisions, and how you evaluate the patterns you choose for crafting a solution, forms a pattern in and of itself. We call this the "Pattern of Patterns", and the patterns that you will find in the Tea Garden will, for the most part, follow this pattern. In a sense, this pattern forms the foundation upon which we hope to build the Tea Garden's Pattern Language.

So what is the "Pattern of Patterns"? We have found that approaching a new way of doing things (a new "Pattern", if you will) generally proceeds through 4 phases:

  1. High-Level Evaluation
  2. Narrowing of Candidate Approaches
  3. Adoption
  4. Dealing with the Consequences

Within the Tea Garden project, we explore an array of patterns, presenting each with a concise overview, a comparison of possible approaches with a focus on Gaiwan's choice, and a discussion on common challenges with solutions. This structured exploration aims to equip users with the necessary insights to effectively implement these patterns, and hopefully elevate their software development practices.

Conclusion

For Alexander, a Pattern describes a set of relationships between building or environmental elements that, when followed, help to resolve tensions and inner contradictions that exist within the larger system. This is a very useful framing. Much of the software pattern literature talks about "forces" rather than "tensions". We prefer "tension", since this is also what one feels while working on these systems. Trying to combine elements in software design is not always straightforward. The software pushes back. It creates tension, and we as developers and architects feel that tension within us. A good pattern will allow us to resolve these tensions, and when we reach that point we will literally experience a feeling of resolution and release.

By applying these patterns, and resolving these tensions, we can hope to approach a Timeless Way of Building Software. Software that is imbued with the quality without a name. Alive, whole, elegant, precise, ego-less, eternal, free from inner contradictions.