Conception d'un logiciel en couches (Node js)

Maerik ayina
Javascript
Javascript NodeJS

Bonjour voici un exercice sur lequel je suis bloqué. Pour dire vrai je ne sais par ou commencer, quelqu'un pourrais m'aider a le réaliser ?

L'objectif est de construire un projet qui divise le logiciel en couches.
C'est ce qu'on appelle la séparation des préoccupations.
Quelques fonctionnalités attendues sur la base du diagramme de classe attaqué :

  • Obtenir une liste d'unités de travail avec leur nom, le site de travail, la taille de l'unité, la dernière date active et la capacité de flexion.
  • Filtrer la liste des unités de travail par le statut du site de travail (actif, inactif) et la capacité de flexion.
  • Ajouter une nouvelle unité de travail avec le nom, le nom d'affichage, le port (opt), le site de travail, la date de début d'activité, la date de fin d'activité (opt),
    description (opt), IDCode (opt), lieu de travail, compétences, compétences supplémentaires (opt).
  • Définir l'horaire des équipes (Une liste d'équipes). Une équipe est décrite par une position, l'heure de début d'équipe en nombre
    l'heure de fin de poste en nombre, l'heure de début de repas en nombre, l'heure de fin de repas en nombre, une liste de jours de repos (du lundi au dimanche),
    le nombre de jours décalés.
    En suivant les schémas d'architecture fournis, réalisez un système qui soit :
    Indépendant des frameworks :
    L'architecture ne dépend pas de l'existence d'une bibliothèque de logiciels riches en fonctionnalités.
    Cela vous permet d'utiliser de tels frameworks comme des outils, plutôt que de devoir faire entrer votre système dans leurs contraintes limitées.
    Testable :
    Les règles de gestion peuvent être testées sans l'interface utilisateur, la base de données, le serveur Web ou tout autre élément externe.
    Indépendant de la base de données :
    Vous pouvez remplacer Oracle ou SQL Server par Mongo, BigTable, CouchDB ou autre. Vos règles de gestion ne sont pas liées à la base de données.
    Indépendant de tout organisme externe :
    En fait, vos règles métier ne savent tout simplement rien du tout du monde extérieur.
    N.B :
    • N'UTILISEZ PAS DE FRAMEWORKS BACKEND (ex : NestJs, ExpressJs, Fastify) : Le but ici n'est pas d'écrire une api. Vous
      Vous n'avez pas besoin d'implémenter les contrôleurs et les points de terminaison. Mais l'architecture devrait être aussi flexible que nécessaire pour utiliser
      la logique métier pour implémenter plus tard les contrôleurs et les points de terminaison.
    • N'UTILISEZ AUCUN CONNECTEUR OU LIBRAIRIE DE BASE DE DONNEES (par exemple : mysql2, sequalize, typeorm, slim-ef) : Vous n'avez pas besoin
      d'implémenter les couches de base de données. Mais l'architecture doit être suffisamment flexible pour utiliser les entités présentes
      dans la logique métier de base pour construire le schéma de la base de données.

lien de schemat
https://user.oc-static.com/upload/2022/01/03/16412413684787_CleanArchitecture.jpg
https://user.oc-static.com/upload/2022/01/03/16412414185484_clean-architecture-class-diagram-generic.png
https://user.oc-static.com/upload/2022/01/03/16412414944704_system-class-diagram.jpg

1 réponse

Julien THOMAS

Salut !
Si ton projet est très orienté clean architecture, Je te conseille de te renseigner beaucoup sur ce projet.
Certains concepts de la clean architecture ne sont pas implémentable en JS, notament à cause de la structure en Interface. Typescript est nécessaire dasn ce cas

Cependant, si ton projet est de faire un simple système imbriqué, je te conseille de faire une Classe par action, (par exemple une classe par entité, une classe par repository pour query tes entités), et ensuite, tu défini un système de storage dans ton repository qui serait simplement une classe et un stockage non persistant in memory.

Ca donerait un truc du genre :

entities/work-unit.entity.js qui contient la classe WorkUnit, avec en propriétés ses champs, optionnels ou non.
entities/team.entity.js qui contient ta classe Team
repositories/work-uint.repository.js qui contient ta logique de stockage et de récupération des WorkUnit. Ton repo contient :

  • Un storage, donc un simple tableau contenant des objets WorkUnit
  • une fonction validate qui valide la structure de ton entité (présence des champs obligatoires)
  • une fonction getAll(options) qui te renvoit les WorkUnits. options est un objet qui peut contenir {actif: true, capacity: 10} pour filtrer tes resultats. les options seront optionnelles
  • une fonction getById qui te renvoit une seule WorkUnit.
  • une fonction addNew(workUnit) qui ajoute une nouvelle unité
  • une fonction delete(workUnitId) qui supprime une workUnit définie
  • et ainsi de suite, suivant les usecases.

Tu fais la même chose pour le repository de l'entité Team

Ainsi, chacune des règle que tu implémente dans ton repository est indépendante du DBMS que tu utilise, ou même sans UI. Tu peux dailleurs tester facilement :
Tu instancie un repository, tu ajoute une entité et tu vérifie si elle est bien entrée dans ton stockage non persistant (tableau de WorkUnit)

Voilà, maintenant let's work ;)