1.1 Scope of this work
Defining the scope coincided with the literature review to prevent unnecessary overlap with existing works. This work considers the following criteria for choosing patterns.
1.1.1 Distributed application patterns
Patterns have to exclusively pertain to distributed systems. Each pattern has to involve at least two discrete components. This work does not strive to rebrand existing monolithic system patterns unless they exhibit unique characteristics when applied to distributed systems, such as Event Sourcing (see § 10.6) or CQRS (see § 8.5), and not patterns such as Cache-Aside, which is a technique universal to any system, or Index Table, which is a database design pattern.
1.1.2 Application architecture patterns
Patterns have to pertain to application architecture, i.e. not algorithms (such as specific leader election algorithms), data management principles, or specific technologies (such as cloud services, databases or message brokers). They should be future-proof and without a vendor bias.
Defining software architecture is hard [1, 2, p. 3, 3, p. 527] – this work settles on the heuristic that the patterns have to have a visualisable structure to be considered architectural.
As such, this work does not aim to cover messaging patterns in general, which were already covered by Hohpe et al. [4] and stood the test of time well, data replication patterns, which were extensively covered by Joshi [5], or the basics of information security, such as asymmetric encryption or certificates.
1.1.3 Design patterns
The patterns have to be design patterns, i.e. not strategies, tactics, overall architectural styles (such as SOA or microservices), methodologies or anti-patterns. Architectural styles were already extensively covered by Richards et al. [2] and Klimešová [6].