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),
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.