“Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context” (Gamma, Helm, Johnson, & Vlissides, 2009). The “Gang of Four” introduced the principles of design patterns and offered a catalog of them. Their 23 patterns are considered the foundation for all other object oriented software design patterns.
“Patterns for system architecting are very much in their infancy. They have been introduced into TOGAF essentially to draw them to the attention of the systems architecture community as an emerging important resource, and as a placeholder for hopefully more rigorous descriptions and references to more plentiful resources in future versions of TOGAF” (The Open Group, 2014).
“In TOGAF, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so” (The Open Group, 2014).
“Pattern techniques are generally acknowledged to have been established as a valuable architectural design technique by Christopher Alexander, a buildings architect, who described this approach in his book The Timeless Way of Building, published in 1979. This book provides an introduction to the ideas behind the use of patterns, and Alexander followed it with two further books (A Pattern Language and The Oregon Experiment) in which he expanded on his description of the features and benefits of a patterns approach to architecture.
Software and buildings architects have many similar issues to address, and so it was natural for software architects to take an interest in patterns as an architectural tool. Many papers and books have been published on them since Alexander’s 1979 book, perhaps the most renowned being Design Patterns: Elements of Re-usable Object-Oriented Software. This book describes simple and elegant solutions to specific problems in object-oriented software design” (The Open Group, 2014).
(Erl, Cope, & Naserpour, 2015) Defines a design pattern as a proven design solution for a common design problem which is formally and consistently documented. The book aims to provide a master design pattern catalog for cloud computing. (Arcitura Education, n.d.) Presents a complete and actualized list of them.
“Cloud computing patterns are applied via the implementation of individual or combinations of different technology mechanisms. Together, the documentation of patterns and mechanisms provides an extremely concrete view of cloud architecture layers and the individual building blocks that represent the moving parts that can be assembled in creative ways to leverage cloud environments for business automation. Each design pattern in the cloud computing catalog is associated with one or more mechanisms” (Arcitura Education, n.d.).
According to (Erl, Cope, & Naserpour, 2015), design patterns, compound patterns and mechanisms relate to each other as following:
- Mechanisms represent technology artifacts that can be combined to form cloud technology architectures.
- Design patterns represent proven solutions to common problems.
- Cloud computing design patterns are (partially or entirely) applied by implementing different combinations of cloud computing mechanisms.
- Compound patterns are comprised of specific combinations of core (required) and extension (optional) member patterns.
“The best way to use patterns is to load your brain with them and then recognize places in your design and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse” (Freeman, Freeman, Sierra, & Bates, 2004).
Applying design patterns to the real world problems, requires knowledge and experience; it is the old combination of science and art. Like Albert Einstein said: “After a certain high level of technical skill is achieved, science and art tend to coalesce in esthetics, plasticity, and form. The greatest scientists are always artists as well”.
References
Arcitura Education. (n.d.). Cloud Patterns. Retrieved from Cloud Patterns: http://www.cloudpatterns.org/
Erl, T., Cope, R., & Naserpour, A. (2015). Cloud Computing Design Patterns. Prentice Hill.
Freeman, E., Freeman, E., Sierra, K., & Bates, B. (2004). Head First Design Patterns. O’Reilly.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2009). Design Patterns. Addison-Wesley.
The Open Group. (2014). TOGAF Version 9.1. Van Haren Publishing.
I find patterns for system architecting very interesting. TOGAF defines four levels of architecture: business, data, and application technology. Each of those architectures have their own patterns. Regarding system architecture, I believe that requires all four plus an additional pattern for integration. That is a lot of specialty knowledge! I know that it is an emerging resource, but do you think it will actually mature? It’s one thing to draw diagrams and implement a proprietary solution; it is another thing to build a generic component that can become off-the-shelf software. It’s the latter, I think, that will be gold for things like cloud computing. Do you think there is any connection between system architecture patterns and Infrastructure-As-A-Service?
LikeLike
I think this link would be helpful: https://blogs.technet.microsoft.com/privatecloud/2014/11/10/microsoft-infrastructure-as-a-service-design-patternsoverview/
LikeLike