Remise 1

La première remise est le 1er octobre 2020.

Au cours de cette itération, nous avons :

Déterminé notre architecture de base
Construit nos pipelines de CI et CD
Documenté notre API avec RAML
Remis une documentation C4
Complété les récits 1 à 4 de l'aventure 1

Récits

Notre remise 1 comporte les récits 1 à 4 de l'aventure 1. Tous ces récits sont complétés.

Burndown chart

Burndown chart de tous les récits complétés

Burndown chart par récit

Architecture logicielle

Notre logiciel se définit selon une architecture hexagonale (ports and adapters architecture). Notre domaine est au centre de cette architecture.

Nos couches externes (les ports) sont :

api : Les ressources REST
infrastructure : La persistance dans la mémoire vive
filesystem : La gestion des fichiers de système
smtp : L'envoi de courriel
console : L'écriture dans la console (pour remplacer l'envoi par la poste)

Entre les couches externes et le domaine se retrouvent les couches :

assemblers : Pont entre les DTOs et objets de domaines
services : Orchestration du domaine, indications aux différentes classes dans un ordre précis
exceptions : Les erreurs possibles dans l'application

Notre structure de fichier est composée d'abord en module (accounts, parkings, ...) puis en couche (api, domain, ...).

Documentation C4

Le diagramme C4 a été fait avec diagrams.net (ancien draw.io). Ce lien permet de visualiser ces diagrammes dans diagrams.net de façon interactive.

Contexte

Container

Component

Design patterns

Utilisés dans le logiciel

Service layer : Afin d'orchestrer les opérations dans notre domaine, nous utilisons des classes de service. Celles-ci s'occupent simplement d'administrer qui fait quoi et quand. Ces classes s'occupent de l'ordre logique des choses, plutôt que des algorithmes agissant directement sur les données.
Repository : Pour accéder à notre persistance depuis le domaine, nous utilisons un interface de Repository injecté dans nos services. Notre persistance actuelle est simplement sauvegardée dans la mémoire vive.
Assembler : Pour faire le pont entre nos objets de domaine et nos DTOs, nous utilisons des classes permettant d'assembler un objet d'une couche à une autre.
Factory : Afin de construire un objet de domaine valide, nous utilisons des classes de création. Ces classes permettent de construire un objet en fonction de certains paramètres et/ou de lui donner un identifiant unique (id, code, ...).
Object Mother : Nos tests utilisent des valeurs aléatoires. Ces dernières doivent être valides selon nos règles d'affaire. Pour cela nous utilisons des classes possédant des méthodes statiques de création pour différents attributs de nos objets de domaine.
Builder : Afin de construire des objets de domaine avec des valeurs aléatoires toujours valides selon nos règles d'affaire, nos tests utilisent des classes de construction. Nous jumelons ce concept à celui d'Object Mother. Au sein de nos tests, on peut retrouver un objet de domaine avec Object Mother et sans Builder, mais jamais l'opposé.
Dependency Injection : Nous utilisons des classes d'injection pour chaque module de notre application. Les ressources de notre API REST sont donc enregistrées dans la configuration des ressources de notre serveur avec tous les objets nécessaires au démarrage et au fonctionnement de l'application.
Exception Mapper : Lorsqu'une exception est lancée dans notre application, nous voulons afficher un message clair à l'utilisateur sous un format JSON approprié et avec le status HTTP associé. Pour cela, nous avons des mappers qui s'occupent de construire et de répondre un objet représentant l'erreur.

Considérés, mais pas encore implantés

Observer : Pour l'envoi de courriel en écoutant ce qui se passe dans les services. Nous avons décidé de l'omettre pour l'instant, puisque l'utilisation est encore assez simple. Par contre, en ajoutant l'écriture dans la console pour faire office d'envoi postal, nous avons réalisé qu'un Observer serait utile. Il sera ajouté à la remise 2.
Strategy : Pour le calcul du montant dû à cause d'infractions, nous avons pensé injecter une stratégie de calcul à l'objet de domaine Bill. Ceci est une amélioration prévue pour la remise 2.
Bridge : Afin d'obtenir le bon fichier, nous avons pensé utiliser le patron de conception Bridge, qui permettrait d'injecter dans nos classes de calcul une classe permettant de lire un fichier et d'en ressortir les données. Nous n'aurions ainsi pas à lier le concept de type de fichier à classe qui ne sert qu'à calculer. Ceci est un changement à venir.

Considérés, mais pas retenus

Au courant de la remise 1, aucun patron de conception n'a été considéré mais pas retenu.

API

Les routes disponibles dans nos GitHub Pages. Ces pages sont générées via une représentation de notre API REST en RAML.

Dette technique

La couche filesystem est utilisée par le domaine dans le module offenses. Cette partie a été faite à la fin du développement de la remise 1 et devra être refaite en partie. Nous utiliserons plutôt des patrons de conception nous permettant de ne pas dépendre de technologie externe au domaine dans le domaine.
La validation d'infractions ne tient pas compte de la journée de validité de la vignette, puisque les critères d'acceptation indique qu'il faut entrer l'heure, mais pas la date. Cela pourra être corrigé à la remise 2 si besoin est.