1.3 Selection process
This work gathers patterns from the sources defined in § 1.2 and selects those that meet the criteria defined in § 1.1. As patterns have to be “rooted in practice” [7, p. 10], it requires contemporary secondary sources to validate the patterns’ ongoing relevance and applicability, as it does not strive to simply rephrase patterns.
Such a cutoff is inherently subjective, but necessary due to the change in landscape observable in the literature. This work settles on defining “contemporary” as anything that was released after containers and cloud – two technologies that shaped the landscape the most – became prevalent.
If a pattern is omitted in a later edition of a book, this work also omits it.
Some authors define pattern boundaries differently. This work tries to handle these situations by using the highest fidelity possible. On the other hand, if different authors define different patterns that result in the same structure, this work discusses their differences under one name instead.
These kinds of conflicts require name resolution. This work balances the following pillars.
Familiarity. The name should match the original as close as possible. The reason is twofold: to facilitate knowledge carryover and to enable easy cross-referencing. If a different name is chosen, the original name is mentioned in parentheses.
Descriptiveness and intent. Each name should prime the reader for the pattern’s goals and means as comprehensively as possible. It should not require additional context or knowledge to be understandable [26, p. 26].
Uniqueness. The pattern name should not clash with other existing patterns used in different contexts to prevent confusion.
Unfortunately, these pillars are often in conflict and require a subjective decision. This is documented alongside the pattern.
1.3.1 Categorisation
Most of the literature reviewed in § 1.2 categorises patterns by what they are, but this requires the reader to analyse the whole catalogue to find patterns to solve a particular problem. Instead, this work categorises patterns by intent so as to give the reader a clear motivation for each pattern and provide a clear path for readers aiming to solve a specific problem.
Eight major categories were identified in the patterns selected for this work; these are detailed in § 3.2. Each pattern is categorised by its primary intent, but it may belong to multiple categories secondarily. This is detailed at the start of each chapter. Thus, instead of having to provide a guide on how to reach the desired solutions, this work aims to bake this information directly into its structure.
Other categorisations were considered but created issues, such as the following. Creating a messaging category would be useful to quickly identify which patterns require messaging brokers, but this would mean that patterns in §§ 4.3, 6.1 and 10.5 would need to be split or would cause confusion, as messaging is not necessarily part of them (even if it often is). Creating a category for communicating with persistent data stores creates a similar issue, such as with § 10.1. On the other hand, traditional structural or behavioural categories from [24] would mostly only overlap due to the implication of the scope defined in § 1.1.
Ultimately, they were discarded due to their incompatibility and limited usefulness. In the end, patterns should never be applied unless they solve a specific problem [24, p. 41], and this work aims to facilitate this.