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 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:
- Monolithic application
- Pipes and filters
An Architectural Style can be implemented in various ways, with a specific technical environment, specific policies, frameworks or practices.
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:
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?).
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.
2004 – Microsoft – Understanding Service-Oriented Architecture
2009 – Microsoft – Microsoft Application Architecture Guide
2010 – Stack Overflow – What’s the difference between Arch. Patterns and Arch. Styles?
2014 – George Fairbanks – Architecture Patterns vs. Architectural Styles
2017 – Wikipedia – List of software architecture styles and patterns
30 thoughts on “Architectural Styles vs. Architectural Patterns vs. Design Patterns”
Great article! Some books tryes to separate these definitions as you did, but they use very abstract terms and as the content of the book unrolls the author sometimes mixes these definitions or use synonyms that make their distinction even harder. Your defintions were very clear and stratight to the point.
Not sure that MVC and MVVM are architectural patterns. I consider them as Design Patterns because they describe an internal estructure and the relationship between some classes or internal modules to get a solution. Instead, an architectural pattern represents the relationship between components of all entire system and each of then are composed by little modules.
LikeLiked by 1 person
I totally understand your take on this and agree that it does make some sense.
Nevertheless, I think it has an impact on the whole way we structure the application presentation layer, so I feel the scope is higher than that of design patterns.
Making a quick search on google for “model-view-controller”, I see Mozilla calls it a “software architecture pattern” while Apple calls it a “design pattern”.
In the end, I think the border is quite blurred and we shouldn’t fall into the trap of putting too much time debating semantics with ourselves (I do that sometimes).
But thank you for sharing your view. 🙂
Wow, really good article!!
10x bro 🙂
To me architecture styles is a specific solutions to a particular software so AP -> AS -> DP not AS-> AP-> DP
Nice article : Top 10 Programming Architectural Patterns
LikeLiked by 2 people
Reblogged this on Tour In Developer Life.