# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 2 Background and Related Work
### Software Design Patterns  
In software engineering, patterns are tools or means for architects and engineers to design robust and well-designed systems or applications [17]. In general, they are reusable solutions to commonly occurring problems within a given context in software design, captured in a way that allows their successful reuse. They are not a specific piece of code, but, rather, are a general concept of solving a particular problem. The principle of patterns originated as an architectural concept proposed by [PERSON] et al. [18]. They described in detail several patterns that serve as generic guiding principles for architectural design, and suggested documenting architectural plans, from regional plans to interior design [19]. They defined a pattern as a description of a problem that occurs repeatedly in our environment, accompanied by a description of the solution to that problem in such a way that this solution can be used a million times without performing it the same way twice [18]. Their book, entitled _A Pattern Language_, is also credited with inspiring the development of object-oriented programming (OOP) languages [19] and advances in software engineering, where patterns emerged in 1987 when [PERSON] and [PERSON] presented the idea of applying patterns to OOP using Smalltalk [20]. The rise of the patterns approach in the field of computer science arose after 1994, when a group of researchers, [PERSON] et al. (usually called the Gang of Four--GoF), published the book _Design Patterns: Elements of Reusable Object-Oriented Software_, defining a collection of design patterns for developing object-oriented software [21]. Since then, the number of design patterns, their popularity, and their application has increased drastically, as software engineers have recognised their advantages [22], which are outlined as follows. (i) Existing patterns present a toolkit of solutions for solving common design problems. They are usually tested extensively and used widely by other developers. Therefore, they provide tested and proven paradigms. (ii) They can be reused in new designs as the best possible solution for a particular problem, as they capture best practices and lessons learned during software development, speeding up the development process. (iii) They define a common language between developers, as they are defined by an expressive name allowing effective communication [17; 22]. (iv) They are crucial in forward engineering, where their use increases quality, readability, and documentation, and in reverse engineering, where they help to understand the software and the rationale behind solutions [22]. However, despite these benefits, their use must be evaluated carefully and not taken for granted. Using the wrong pattern, inappropriate for a specific use case, can be detrimental and increase the complexity of the software [17]. Patterns can be grouped into three categories: (i) architectural patterns, (ii) design patterns, and (iii) idioms. (i) Architectural patterns define the general structure of applications, such as elements and the connections between them, and represent the highest level of abstraction. (ii) Design patterns define the way modules, classes, or components are organised to solve problems, while (iii) idioms represent code-level solutions to problems related to a specific programming language [17]. Patterns are formalised best practices, described in a way that allows common design problems to be solved without reinventing the wheel. They are documented in a way that allows their reuse in numerous situations, often using a pattern template. However, various template formats have been used for defining patterns by different authors, the most prominent being the GoF pattern format proposed by [PERSON] et al. and the template proposed by [PERSON] et al. Both approaches encapsulate an expressive _name_, a _context_, and a recurring _problem_ that the pattern solves.