Chapter 11: Applying the Patterns

Overview

Looking at the diagrams in the previous chapter, you may be thinking that the GlobalTech architecture is rather more complex than the architecture of the system you work with or are planning to build. Or maybe you're thinking that the architecture looks somewhat simplistic – where is the edge caching, multiple data-centre failover and top-level security? If we're lucky, you'll be thinking that GlobalTech looks a bit like your system and you're glad to see that someone else has built something similar.

The GlobalTech architecture is clearly an exemplar – albeit one that is an amalgam of a number of real systems that the authors have been involved with (so whilst it has never actually been built, other systems that look a lot like it have been built). It is not as complex as the most complex of these systems but quite a bit more complex than the simplest. Ultimately, the GlobalTech architecture is a product of the functional and non-functional requirements placed on it. In this chapter we will look at a simpler architecture that can be evolved using the patterns in this book – an ‘entry-level’ high capability system if you like – and then examine how applying the patterns can produce still further architectures. This is not an academic exercise but is intended to explore how subtle changes in requirements and implementation choices can change the shape of the system and how the rest of it is implemented. An increase in the absolute level of a particular non-functional requirement may change the number and type of patterns applied. Even if the same patterns are applied in two systems, the decision to implement one of them differently can have knock-on effects for the implementation of the patterns with which it interacts. This can make the overall implementation of the two systems quite different.

The architecture of each system will be based on its functional and non-functional requirements. The number of possible combinations of varying degrees of requirement is huge. Also, there are multiple implementation choices for each pattern you apply to address these requirements. Given such a myriad of possibilities, we need a starting point from which to explore some variations, so we start with a simple system.