4.design.tex (5323B)
1 \chapter{Design} 2 3 \section{Approach} 4 5 In this project, the approach used is Domain Driven Design (here after DDD). This approach, originally introduced by Eric EVANS in an over-rated book called BlueBook, considers that the domain/business of the application is far more valuable than the technique and should therefore be put first. 6 7 There are 2 aspects to this theory: strategy and tactics. 8 9 \begin{figure}[H] 10 \centering 11 \includegraphics[width=\textwidth]{strategical-vs-tactical} 12 \caption{DDD Strategical concept vs Tactical concept} 13 \label{fig:design-strategical-vs-tactical} 14 \end{figure} 15 16 The figure above lists the main patterns used in the project, both strategic and tactical. The strategic patterns are more conceptual and mainly used for modelling, whereas the tactical patterns are standard design patterns. 17 18 \section{Technologies} 19 20 The technologies used are listed below: 21 \begin{itemize} 22 \item \textbf{Typescript}: superset of ecmascript (JS) allowing to devéloppé in JS with a powerful system of verification of type. 23 \item \textbf{Libsodium}: serious library written in C that allows to perform various cryptographic tasks. Used for encryption / token authentication (see Token Security section) as well as password hashing (see Password Security section). Has a JS/TS port/module for use in Typescript. 24 \item \textbf{PostgreSQL}: database engine. Chosen because already used by M. Emanuelle BENOIST to be used after the thesis. 25 \item \textbf{Deno fresh}: Small HTTP/HTTPS framework developed in Typescript (modification compared to Adonis previously used by Mr Loïc Fauchière). 26 \item \textbf{Valita}: Small library allowing to make verification / validation of data and allowing to make correspond the Typescript types defined at compilation, but with a runtime verification (validation). 27 \item \textbf{Tesseract}: ORC Engine to scan MRZ on ID Document 28 \item \textbf{Deno}: Secure runtime (change from node used before). 29 \end{itemize} 30 31 \section{Clean architecture} \label{clean-arch} 32 33 The KYCID server software is designed on a "clean architecture" model, as described in reference \cite{CleanArch}. 34 This model is a layered model, but where the domain is the base layer rather than the persistence layer. 35 36 \begin{figure}[H] 37 \centering 38 \includegraphics[width=0.9\textwidth]{software-layer} 39 \caption{Software Layer architecture} 40 \label{fig:arch-software-layer} 41 \end{figure} 42 43 The design comprises three layers: the domain layer, the application layer and the infrastructure and presentation layer. The domain and application layers constitute the core layer. 44 45 \section{Domain layer} 46 47 This is the most elementary layer of the system, so it depends only on itself. There will only be simple classes that model the domain (hence the name) and raise exceptions if invariants are not respected. 48 49 \begin{bfhWarnBox} 50 It is important to distinguish between the domain model and the database persistence model. For instance, in a database, the objective is to avoid duplication. In the domain, it is possible to have two distinct classes representing a user in two different contexts. However, in the database, the aim is to merge these into a single table. 51 \end{bfhWarnBox} 52 53 \section{Application layer} 54 55 This layer constitutes the core of the domain and is dependent on both itself and the domain layer situated directly below. The role of the application layer is to connect the domain with the external environment. In order to fulfil this function, it is necessary to invert control using the port/adapter pattern. This involves creating an interface (port) in the application layer which can be used by the layer but placing the implementation (adapter) in the layer above. It is preferable to place as little business code as possible in this layer and to instead place it in the domain layer. 56 57 It is also necessary for the application layer to prevent the infrastructure layer from depending indirectly on the application layer. For example, exceptions raised in the domain layer must be handled by the application layer. Similarly, it is important to avoid raising exceptions in the application layer. However, exceptions that are raised by adapters should not be handled by the application layer. 58 59 It is not advisable for the application layer to raise exceptions, as this should be the domain layer's responsibility. However, any exception raised in an adapter in the infrastructure layer that is not a domain exception (for example, a connection failure exception) should not be handled by the application layer. 60 61 \begin{bfhWarnBox} 62 The application layer must not depend on infrastructure or technical code that you have not written yourself (avoid complex libraries). 63 \end{bfhWarnBox} 64 65 \section{Infrastructure and presentation layer} 66 67 This layer is responsible for encapsulating all the technical complexity associated with infrastructure and user presentation. It will contain the most direct code to implement the application layer adapter. 68 Not any business logic is included. 69 70 \begin{bfhWarnBox} 71 This layer should be independent of the domain, as it is not directly below it. This principle is linked to the fact that we do not want a change in the domain to imply a change in the infrastructure, nor vice versa. 72 \end{bfhWarnBox}