ChantiePro

Vue d'ensemble

Projet personnel d'ingénierie qui modélise une entreprise de construction en treize services métier et trois services de plateforme. Chaque service possède son schéma PostgreSQL. Les changements que le reste du système doit observer circulent en événements Kafka. Un workspace Angular 18 sous Nx au-dessus ; Prometheus, Grafana, Loki et Zipkin en dessous.

Interface

Problème

Un chantier se comporte comme une petite entreprise : les matériaux arrivent et se consomment, le matériel circule, les équipes pointent, les notes de frais doivent être validées, et chaque événement doit se réconcilier avec un budget. Un monolithe couple chaque changement. L'objectif était de découper un vrai domaine en services déployables séparément, tout en livrant une interface cohérente.

Solution technique

Les requêtes entrent par une Spring Cloud Gateway qui valide le JWT une fois et transmet le principal authentifié. Les services se découvrent via Eureka et chargent leur configuration depuis un config server. Tout ce qu'un autre bounded context doit observer — un projet qui change de statut, une dépense approuvée — est publié sur Kafka plutôt que traité par un appel synchrone. Les données sont scopées par organisation via un organizationId dans le JWT, appliqué à la couche requête. Ce n'est pas un modèle d'isolation multi-tenant durci.

Architecture

Ce que contient le dépôt

• Treize services métier et trois services de plateforme (gateway, Eureka, config server) en Java 21 et Spring Boot 3.3
• Six bibliothèques partagées : DTO, sécurité, Kafka, audit, exceptions, filtres web
• PostgreSQL 16, un schéma par service, migrations Flyway
• Événements Kafka consommés par notification, audit et finance
• Cache Redis, stockage objet MinIO, OpenAPI springdoc
• Angular 18 dans un monorepo Nx, NgRx Signal Store
• Prometheus, Grafana, Loki et Zipkin
• CI : tests Maven sur JDK 21 dont tests d'intégration Testcontainers/Flyway, build Nx de production, validation Compose

Choix techniques

Un schéma par service, pas de base partagée

Chaque service possède ses tables. Aucune jointure inter-services. La déployabilité reste réelle ; toute collaboration passe par une API ou un événement.

Des événements pour les réactions, du REST pour les commandes

Le REST synchrone reste dans le cas d'usage que l'appelant attend. L'audit et les notifications n'ont pas à être sur ce chemin : ils s'abonnent.

Des bibliothèques partagées plutôt que du copier-coller

Filtres JWT, enveloppes d'événements et formes d'erreur vivent dans des modules Maven. Un nouveau service hérite des conventions en déclarant une dépendance.