Vue d’ensemble du projet - nbacheng/nbcio-boot

Fichiers source

Cette page est générée à partir des fichiers source suivants :

Ce projet constitue une plateforme de gestion d'entreprise baptisée NBCIO, basée sur le framework robuste JeecgBoot 3.0. Il s'agit d'une solution monolithique modulaire conçue pour offrir une gestion complète des utilisateurs, des rôles, des départements et des processus métier, tout en s'appuyant sur une stack technique moderne et éprouvée.

Présentation générale et architecture technique

La plateforme NBCIO est une évolution de JeecgBoot 3.0 (datée du 1er novembre 2021), conçue pour centraliser la gestion des ressources d'une entreprise. Elle adopte une architecture modulaire qui permet de séparer clairement les fonctionnalités métier du cœur technique du système. Le projet est structuré pour faciliter le déploiement via Docker et la gestion des dépendances via Maven, assurant ainsi une maintenabilité et une évolutivité optimales.

Stack technologique

L'architecture technique repose sur un ensemble de frameworks et de bibliothèques Java standard dans l'écosystème Spring :

Composant	Technologie	Version	Rôle
Framework Core	Spring Boot	2.3.5.RELEASE	Fondation de l'application et inversion de contrôle
Persistance	Mybatis-plus	3.4.3.1	ORM et accès aux données simplifié
Sécurité	Apache Shiro	1.7.0	Gestion de l'authentification et des autorisations
Token JWT	Jwt	3.11.0	Gestion des tokens d'authentification stateless
Cache	Redis	-	Mise en cache distribuée pour les sessions et données volatiles
Pool de connexion	Druid	1.1.22	Pool de connexions haute performance pour la base de données
Workflow	Flowable	6.7.2	Moteur de processus métier (BPM)

Cette configuration technique est définie dans le fichier racine pom.xml, qui gère également les versions de Spring Cloud (Hoxton.SR8) et Spring Cloud Alibaba, bien que le projet fonctionne principalement en mode monolithique (pom.xml:19-20).

Architecture modulaire

Le projet est divisé en plusieurs modules Maven distincts, chacun ayant une responsabilité précise. Cette structure permet d'isoler les fonctionnalités et de favoriser la réutilisation du code.

Les modules principaux incluent :

nbcio-boot-base : Contient les utilitaires, le cœur (core) et les outils communs à tous les autres modules.
nbcio-boot-module-system : Le module central gérant les utilisateurs, les rôles, les permissions et les logs.
nbcio-boot-module-flowable : Intègre le moteur de workflow Flowable pour la gestion des processus métier.
nbcio-boot-module-im : Module dédié à la messagerie instantanée.
nbcio-module-estar : Un module métier spécifique (nécessitant plus de contexte pour détailler son rôle exact).

Cette modularité est explicitement définie dans la section <modules> du pom.xml.

Structure modulaire et dépendances

La structure des dépendances du projet est conçue pour gérer à la fois les bibliothèques externes et les modules internes de manière cohérente. Le fichier parent pom.xml joue un rôle crucial dans la gestion des versions et des conflits potentiels.

Dépendances externes et internes

Le projet utilise une gestion centralisée des versions via des propriétés Maven. Par exemple, la version de JeecgBoot est fixée à 3.0 (pom.xml:16), et les versions des connecteurs de base de données (MySQL, PostgreSQL, Oracle) sont également standardisées (pom.xml:26-29).

Les dépendances internes sont gérées dans la section dependencyManagement. Le module système (nbcio-boot-module-system) est déclaré comme une dépendance gérée (pom.xml:137-141), tout comme les modules de base (nbcio-boot-base-tools, nbcio-boot-base-core). Cela garantit que tous les sous-modules utilisent la même version des bibliothèques internes, évitant ainsi les erreurs de type "ClassNotFoundException" ou les conflits de version.

Infrastructure et déploiement

Le déploiement de l'infrastructure est facilité par l'utilisation de Docker Compose. Le fichier docker-compose.yml définit trois services essentiels :

nbcio-boot-mysql : Une instance de base de données MySQL mappée sur le port 3306.
nbcio-boot-redis : Une instance Redis mappée sur le port 6379, utilisée pour le cache et les sessions.
nbcio-boot-system : Le module système principal, construit à partir du contexte ./nbcio-boot-module-system et exposé sur le port 8080.

Ce service système dépend explicitement des services MySQL et Redis (depends_on), assurant que l'application ne démarre pas tant que l'infrastructure de données n'est pas prête (docker-compose.yml:35-37).

Gestion des utilisateurs et des rôles

Le module système contient la logique métier centrale pour la gestion des identités et des accès. La classe SysUserServiceImpl est le cœur de cette logique, implémentant des opérations CRUD complexes tout en gérant les transactions et la cohérence des données.

Création et mise à jour des utilisateurs

L'ajout d'un utilisateur avec un rôle spécifique est géré par la méthode addUserWithRole. Cette procédure sauvegarde d'abord l'entité utilisateur, puis associe les rôles fournis en créant des entrées dans la table de liaison SysUserRole (SysUserServiceImpl.java:131-140).

La modification d'un utilisateur (editUserWithRole) suit une stratégie de "suppression puis ajout" pour les rôles. Elle met d'abord à jour les informations de l'utilisateur, puis supprime toutes les associations de rôles existantes pour cet utilisateur avant de recréer les nouvelles associations. Cette approche garantit que les rôles sont toujours synchronisés avec l'état attendu, sans laisser d'orphelins (SysUserServiceImpl.java:145-156).

Une annotation @CacheEvict est utilisée sur ces méthodes pour invalider le cache des utilisateurs (SYS_USERS_CACHE) (SysUserServiceImpl.java:143), assurant que les modifications sont immédiatement répercutées sur l'ensemble de l'application.

Gestion des départements

L'association des utilisateurs aux départements est gérée de manière similaire via addUserWithDepart et editUserWithDepart. La méthode d'édition est particulièrement intéressante car elle gère la suppression des rôles de département lorsque l'utilisateur est retiré d'un département. Elle vérifie si l'utilisateur est retiré d'un département et, si c'est le cas, supprime les entrées correspondantes dans la table SysDepartRoleUser (SysUserServiceImpl.java:341-348).

Rôles et permissions départementales

La classe SysDepartRoleServiceImpl fournit des méthodes pour interroger les rôles spécifiques à un département. La méthode queryDeptRoleByDeptAndUser permet de récupérer la liste des rôles détenus par un utilisateur au sein d'un code organisationnel spécifique (SysDepartRoleServiceImpl.java:22-25). Cela suggère une gestion fine des permissions qui peut varier non seulement en fonction de l'utilisateur, mais aussi de son appartenance à un département.

Intégration et API système

Le projet expose une API interne riche via l'interface ISysBaseAPI, dont l'implémentation SysBaseApiImpl sert de façade pour de nombreux services système. Cette classe centralise l'accès aux données des utilisateurs, des rôles, des dictionnaires et des permissions.

Services de base et dictionnaire

SysBaseApiImpl injecte de nombreux services et mappers pour accéder aux données, comme SysUserMapper, SysRoleMapper, ou SysDictService (SysBaseApiImpl.java:58-93). Elle fournit des méthodes utilitaires telles que translateDictFromTable pour convertir des codes en valeurs lisibles via des tables de dictionnaire (SysBaseApiImpl.java:119-121), ou getUserByName pour récupérer un utilisateur et le convertir en objet LoginUser (SysBaseApiImpl.java:105-116).

Gestion des comptes tiers

L'intégration de systèmes tiers (comme DingTalk ou WeChat) est gérée par SysThirdAccountServiceImpl. Ce service gère le lien entre un utilisateur système et un identifiant tiers.

La méthode updateThirdUserId met à jour le compte tiers pour lier un sysUserId à un thirdUserUuid (SysThirdAccountServiceImpl.java:46-64). Si un compte tiers existe déjà pour ce type de connexion, il est d'abord supprimé avant d'être mis à jour, évitant les doublons.

La création d'un utilisateur tiers (createUser) implique la génération d'un nom d'utilisateur unique (en ajoutant un timestamp si le nom existe déjà) (SysThirdAccountServiceImpl.java:73-78), la création de l'entité SysUser, et l'attribution automatique d'un rôle par défaut nommé "third_role" (SysThirdAccountServiceImpl.java:101-114).

Flux de données et architecture système

Les diagrammes suivants illustrent l'organisation modulaire du projet et le flux de données lors de la création d'un utilisateur avec rôles et départements.

Architecture modulaire

Ce diagramme montre la structure hiérarchique des modules Maven et leurs dépendances principales.

正在加载图表渲染器...

Explication des composants :

nbcio-boot-parent : Le projet parent qui définit les versions et les dépendances communes.
nbcio-boot-base : Fournit les fondations (core, tools) utilisées par les autres modules fonctionnels.
nbcio-boot-module-system : Le module central contenant la logique de gestion des utilisateurs, rôles et départements.
Modules fonctionnels : Flowable (workflow), IM (messagerie) et Estar (métier) dépendent du module système et de la base.

Flux de création d'un utilisateur

Ce diagramme séquentiel détaille le processus interne de création d'un utilisateur, incluant la gestion transactionnelle et la mise à jour du cache.

正在加载图表渲染器...

Explication du flux :

Contrôle et Service : La requête passe par le contrôleur qui appelle le service SysUserServiceImpl.
Persistance : L'utilisateur est d'abord sauvegardé via SysUserMapper pour obtenir son ID.
Association de rôles : Le service parcourt la liste des rôles fournis et insère une entrée dans la table de liaison SysUserRole pour chacun.
Transaction et Cache : L'opération est transactionnelle. Une fois terminée, l'annotation @CacheEvict déclenche le nettoyage du cache Redis pour garantir la cohérence des données.

Conclusion et lecture recommandée

Ce document a présenté une vue d'ensemble de la plateforme NBCIO, en se concentrant sur son architecture modulaire, sa stack technique et les implémentations clés de la gestion des utilisateurs et des rôles. Les modules sont fortement découplés grâce à l'injection de dépendances et à la structure Maven, tandis que la gestion des données est assurée par Mybatis-plus avec un support transactionnel robuste.

Pour approfondir l'analyse, il est recommandé de consulter les sections suivantes :

Architecture détaillée : Pour une analyse plus poussée des design patterns utilisés.
Sécurité : Pour comprendre comment Shiro et JWT interagissent pour sécuriser les API.
Workflow : Pour explorer comment Flowable est intégré pour gérer les processus métier complexes.