Architectural Styles vs. Architectural Patterns vs. Design Patterns

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

In the last post, I wrote about how programming languages have evolved and what it tells us: that they evolved always in the direction of providing for more modularity and encapsulation.

In the following posts, I will write about Architectural Styles and Architectural Patterns evolution, so today I will write about what is an Architectural Style and what is an Architectural Pattern.

As much terminology in Software Development, these terms are not clear and different people give it a different meaning. MSDN says that Architectural Styles and Architectural Patterns are the same things, but personally, I prefer to think of these in the lines of what is explained by George Fairbanks and Michael Keeling, what is said in this stack overflow answers and how Wikipedia separates the two: the key difference is the scope.

It is also important to reinforce the idea that Architectural Styles, Architectural Patterns and Design Patterns are not mutually exclusive, they are complementary and they all can teach us something, although, as usual, they should be used only when needed.

Architectural Styles

Architectural styles tell us, in very broad strokes, how to organise our code. It’s the highest level of granularity and it specifies layers, high-level modules of the application and how those modules and layers interact with each other, the relations between them. Examples of Architectural Styles:

Component-based
Monolithic application
Layered
Pipes and filters
Event-driven
Publish-subscribe
Plug-ins
Client-server
Service-oriented

An Architectural Style can be implemented in various ways, with a specific technical environment, specific policies, frameworks or practices.

Architectural Patterns

A pattern is a recurring solution to a recurring problem. In the case of Architectural Patterns, they solve the problems related to the Architectural Style. For example, “what classes will we have and how will they interact, in order to implement a system with a specific set of layers“, or “what high-level modules will have in our Service-Oriented Architecture and how will they communicate“, or “how many tiers will our Client-server Architecture have“.

Architectural Patterns have an extensive impact on the code base, most often impacting the whole application either horizontally (ie. how to structure the code inside a layer) or vertically (ie. how a request is processed from the outer layers into the inner layers and back). Examples of Architectural Patterns:

Three-tier
Microkernel
Model-View-Controller
Model-View-ViewModel

Design Patterns

Design Patterns differ from Architectural Patterns in their scope, they are more localised, they have less impact on the code base, they impact a specific section of the code base, for example:

How to instantiate an object when we only know what type needs to be instantiated at run time (maybe a Factory Class?);
How to make an object behave differently according to its state (maybe a state machine, or a Strategy Pattern?).

Conclusion

As I mentioned in the beginning of this post, it’s all about the scope:

An Architectural Style is the application design at the highest level of abstraction;
An Architectural Pattern is a way to implement an Architectural Style;
A Design Pattern is a way to solve a localised problem.

Furthermore, a pattern might be able to be used both as an Architectural Pattern or a Design Pattern, again depending on the scope we use it in, in a specific project.