Architecture

1. Introduction

2. Vue physique

La vue physique a pour but de décrit comment devrait être déployé le logiciel selon des nœuds logiques, ainsi que de définir comment ou plutôt par quel moyen les différents nœuds vont communiquer entre eux.

Le dernier but de cette vue est de donner les différentes contraintes de déploiement, comme quelles librairies sont utilisées, quels sont les besoins matériels.

Diagramme de déploiement (niveau spécification)
Figure 1. Diagramme de déploiement (niveau spécification)

Le diagramme ci-dessus montre le déploiement du logiciel sur 4 nœuds logiques. Le nœud logique Server contient les artefacts Java qui correspondent aux modules Maven du code source: API, Doamin et Spring. Le nœud logique Navigateur contient l’artefact Client, qui correspond au paquet JavaScript généré avec Angular. Le serveur communique via le protocole REST avec [*] navigateurs. Les bases de données de test et de production se déploient sur deux nœuds logiques différents, Test Database et Production Database

Diagramme de déploiement (niveau instance)
Figure 2. Diagramme de déploiement (niveau instance)

3. Vue du développement

Ici, nous décrivons l’organisation du code source, sous la forme de modules Maven et Node.js. Notez bien le sens des relations de dépendance entre les modules : par exemple, l’artefact project-api ne doit dépendre d’aucun autre module.

Organisation des modules
Figure 3. Organisation des modules

3.1. Conventions de codage

Le code Java utilise les conventions de codage décrites dans le Google Java Style Guide. Les commentaires suivent le format Javadoc.

Le code TypeScript utilise les conventions de codage décrites dans le Google TypeScript Style Guide. Les commentaires suivent la norme TSDoc.

3.2. Règles de traduction des composants

  1. Les composants implémentés en Java, doivent suivre le JPMS, Java Platform Module System, c’est-à-dire, contenir un fichier nommé module-info.java, qui spécifie les interfaces fournies par le composant, les modules dont il a besoin et aussi les classes qui sont accessibles par d’autres modules.

  2. Chaque composant contient une Façade et au moins un Contrôleur.

    1. Ces deux rôles peuvent être joués par une même classe.

    2. Lorsqu’un composant fournit plus d’une interface, il a aussi plusieurs contrôleurs : autant de contrôleurs que d’interfaces fournies.