Design patterns vs Architectures
In a number of situations, many developers mix-up the terms “design pattern” and “architecture”.
It is true that they share the “pattern” aspect, as a way of thinking and designing software and to be clearer by the way, we should say “software architecture patterns” and “software design patterns”.
They also have in common the definitive product which is the information system or at least a part of it.
But the differences are fundamental at many levels, that is what we will see together in this article.
Level of magic
The most commonly known fact about design patterns is that they are Object oriented solutions to common software design problems. Refer to the original book “Design Patterns:Elements of Reusable Object-Oriented software” by the “Gang of four”. The manipulated elements are at class-level at most, relations between classes, class members … etc
Regarding architecture patterns (commonly called ‘architectures’), we are dealing with higher level problems. We manipulate usually, collections of classes or packages, and we describe the interactions between system-level components, data flows, messages … etc
Homogeneity
Another difference is in the type of objects we work with, in the case of architectural design, we usually put on a diagram more than one type of components. In the design pattern case, we handle one type of entities only.
For example, let’s check this simple microkernel architecture
It is one of the simplest, it contains two types of components, core and plugin.
Variants
It is common for architectures in particular to have variants to adapt it to specific contexts. For instance, if you consider the following big data architecture patterns,
the “kappa” architecture is a variant of the “lambda” one. You can see that the difference is the Batch/Stream processing components that were merged in the kappa architecture.
There are various reasons for coming up with a variant, one of them in this case is the cost of developing and maintaining two different software pieces at the same time.
Hybrids
We could argue that some design patterns could have variants, but the hybrid part is specific and most common for architectures.
As I explained before, the elements that we handle in an architecture pattern are components, we could apply architectures to these parts also.
A good example is the “Service Oriented Architecture ( SOA )” where we could embed many different architectures, by applying for example a layered architecture to one service and a microkernel one to the other… etc.
Conclusion
To sum-up, I would say that the architecture pattern is the way we design the ground on which the system runs. And that the design pattern is a structured way of solving an OO common problem in the underlying code running in the different components of the system.
