What's this pattern's level of abstraction? It depends.

In building architecture we often easily recognize when one pattern fits into another pattern. Perhaps this is because physical things are easier for us to touch, feel, see, and sense. For example, in A Pattern Language book, Christopher Alexander clearly shows how building and city planning patterns fit with each other. Take the Activity Pockets pattern as an example. The essence of this pattern captures the fact that in order for an open public space to be vibrant and lively it needs to have a set of activity pockets at its edges. As the number of activity pockets expand the whole open space becomes lively. So if an urban designer’s design goal is to create a lively public space he or she may choose to apply this pattern. This pattern (#124) “helps complete the edge of all these larger patterns … Promenade (#31), Small Public Squares (#61), Pedestrian Street (#100), Building Thoroughfare (#101).” At the same time this pattern is further refined by the following downstream patterns: Arcades (#119), Trellised Walk (#174), Sitting Wall (#243), just to name a few. It’s easy to see the granularity level of the Activity Pockets pattern in the context of a city and a building.

The above mentioned pattern makes sense, especially when combined with a topology map, but what about software patterns?

In the software architecture world the granularity of a given pattern is not always obvious. In case of well known patterns, such as client server or its derivative N-tier, everyone knows that they represent a systemic level of abstraction. But less known patterns may confuse architects, especially if some patterns is widely recognized as systemic, but is encapsulated inside of some other systemic pattern. For example, a 3-tier overarching architecture may have a data repository pattern (also known to sit at a systemic level of abstraction) hidden at the next level of decomposition in the data tier.

The key to dealing with potential confusion is to clearly explain (and document) patterns used and why. Further, maintaining a proper perspective (i.e. dynamic, static, or physical), as mentioned in the previous post, is critical when showing how one patterns supports another pattern.



Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com


Comments

Popular posts from this blog

Why we do agile

Quality Attribute Refinement