The pattern format: an antidote to hype

pattern  

---

---

I regularly read articles advocating for the use of a particular technology. Recent examples include “S3 is a great storage backend” or “your monolith’s modules should communicate via a message broker”. While these articles are often informative, they are also typically one-sided. They focus on the benefits of the solution and ignore the drawbacks. This is a problem because every solution has drawbacks. And, if you don’t consider the drawbacks, you might choose a solution that doesn’t work for you.

In this article I describe a better way to structure an article: the pattern format. You will learn how it provides a balanced view of a solution. Let’s first look at the structure of a pattern.

What’s a pattern

A pattern is reusable solution to a problem occurring in a context and its consequences There are a few different ways to structure a patterns. My favorite consist of the following elements:

1. Context - the situation within which the pattern is applicable
2. Problem - the problem that the pattern solves
3. Forces - the issues or concerns that you must consider that can determine the suitability of a solution
4. Solution - the solution that the pattern proposes
5. Consequences - describes the consequences of applying the pattern
6. Related patterns - patterns that either solve the sub-problems created by this pattern or are alternative solutions to the same problem

Let’s look at the consequences and related patterns sections in more detail.

Patterns highlight consequences

A valuable part of a pattern is its consequences. The consequences consists of the following elements:

• Benefits - the positive outcomes of applying the pattern
• Drawbacks - the negative outcomes of applying the pattern
• Issues - the sub-problems that are created by applying this pattern

As you can see, you cannot simply describe the solutions benefits. You also must describe its drawbacks and the sub-problems that it creates.

A pattern is requires you to consider the pattern’s issues, which are the sub-problems that are created by applying this pattern. The issues highlight the fact that there are no silver bullets. They are also extra work that you must take on if you choose to apply the pattern. For example, the Microservice architecture pattern introduces the sub-problem of needing to implement commands and queries that span multiple services. As you will see in the next section, these issues are often solved by applying other patterns.

Patterns reference other patterns

The related patterns section is also important. It consists of the following elements:

• Successor patterns - patterns that solve the sub-problems created by this pattern
• Alternative patterns - different ways of solving the same problem

Let’s first look at successor patterns.

About successor patterns

As mentioned above, applying a particular pattern often introduces sub-problems (the pattern’s issues). These sub-problems are often solved by applying other patterns. For example, distributed commands and queries are implemented using the service collaboration patterns.

Patterns point to alternative solutions

A pattern should also reference any alternative patterns, which are different ways of solving the same problem. A pattern cannot pretend that it’s the only solution to a problem. It must acknowledge that there are other solutions, which usually have different trade-offs. For example, an alternative to the Microservice architecture pattern is the Monolithic architecture pattern.

The pattern format is an antidote to hype

IMHO A great many articles and presentations that I’ve seen over the years would be improved by using the pattern format. Even adding a brief description of the drawbacks would have dramatically improved their quality. I would, however, recommend going further and including all the pattern format’s sections described at the start of the article.

The downside of using the pattern format: less hype

But naturally there’s are downsides to use the pattern format! It’s a lot more work to think through the consequences, issues, and related patterns. What’s more, it’s less exciting. And, developers are human and humans like hype and excitement.

However, we can only build great software if we have an informed view of the technologies that we use. We must have a through understanding of each technology’s benefits, drawbacks and issues.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help