Design Patterns Thinking and Architecture at Scale
I am doing a talk at the Agile Technical Conference called Design Patterns and Architecture at Scale. It is about the relationship between Design Patterns thinking and architecture at scale. I thought the basis of the talk would be of interest.
People often have difficulty creating and maintaining application architectures. While test-driven development, automated testing and continuous integration are great practices to facilitate local design and making changes without risk, the architecture within which these changes take place will have a large impact on the effort required.
The Agile community is recognizing the need to address the challenges of Architecture at Scale. While many people recognize the importance of patterns, they tend to focus on patterns as a set of solutions. This often leads people to try to create designs by combining patterns together. This is actually the anti-thesis of the true intention of design patterns. Patterns thinking as espoused by Christopher Alexander (author of Timeless Way of Being which inspired the patterns community) means to use patterns as a way of creating a design from the big picture, adding more detail with each pattern being added.
Patterns are actually a way of thinking. The design patterns themselves are a result of this thinking. On quick examination of most design patterns, one can readily see the patterns are used to encapsulate some variation (e.g., algorithm, # of items, order of execution, …).
While the defined patterns are very useful to know and use, it is the thought process underneath them that is much more powerful. The essence of design patterns thinking is:
- Understand the forces in the problem you are trying to solve
- Reduce the complexity of these forces by making a distinction between the issue and potential implementations
- Create a simplified model of the issues to be managed in the application – in particular those issues that tend to vary
While design patterns live at the code level, these concepts live from code to high level design. The trick is to create a way of applying these technique at much greater scales. Fortunately, this technique already exists – commonality-variability analysis – introduced by James Coplien and extended with the analysis matrix by Al Shalloway. Using CVA, one can take these concepts up to any scale.
The result of these methods is to create an architecture where all variations are encapsulated and the relationship between concepts is greatly simplified. This is particularly important in what I call high-variability domains. These are domains where many concepts exist and each one has a variety of implementations. Code implementing these domains often have many switches in them, often embedded switches. Changing code like this is difficult because the coder always needs to understand the situation one is in and how it relates to several other cases.
The power of design patterns is that they both reflect the domain as well as provide a set of options on how to implement the domain in a manner that, by encapsulating the variations present, easily enable adding new variations. This is exactly what an architecture is intended for.
If you want to learn more, we have workshops both on design patterns and agile architecture. Please drop me a note at email@example.com if you have such interest.