Projet de Synthèse

Changelog — V0.2.0

• Refonte des illustrations SVG pour supprimer les chevauchements de texte.
• Le schéma Clean Architecture passe en couches lisibles avec dépendances orientées vers le domaine.
• Les deux illustrations sont agrandies dans les slides pour redevenir lisibles en projection.
• Les libellés des liaisons métier sont redessinés en étiquettes lisibles sur la carte du domaine.
• La carte du domaine est resserrée pour occuper davantage la slide utile et améliorer la lecture à distance.
• Les blocs métiers sont rehaussés pour éviter tout rognage des dernières lignes de texte.
• Les libellés de liaison sont déplacés hors des boîtes pour ne plus masquer les entités.
• Les blocs sont davantage espacés pour redonner de la place aux étiquettes de flux.
• La carte du domaine est réorganisée autour de relations métier plus justes : demande, ressource ciblée, règles consultées et événement émis.
• Le SVG est nettoyé et stabilisé pour éviter tout artefact visuel lors du rendu Marp.
• Les étiquettes et flèches sont repositionnées pour supprimer les chevauchements restants.
• La carte est scindée entre coeur métier et effet externe pour privilégier la lisibilité pédagogique.

Vue d'ensemble du système cible

Illustration des couches

Coeur du domaine réservation

Effet externe : notifications

Contraintes du projet

• Séparation stricte Domain / Application / Infrastructure / Api.
• Usage intensif d'interfaces pour les frontières.
• Injection de dépendances obligatoire.
• Couverture de tests sur les règles métier.
• Persistence simulée ou réelle derrière un repository générique.

Cas d'usage emblématiques

• Réserver une ressource sur un créneau.
• Refuser le chevauchement.
• Annuler une réservation.
• Consulter le planning agrégé d'une ressource.
• Journaliser les actions importantes.

Squelette de solution proposé

src/
  Booking.Domain/
  Booking.Application/
  Booking.Infrastructure/
  Booking.Api/
tests/
  Booking.Domain.Tests/
  Booking.Application.Tests/

Critères d'évaluation

• Le domaine compile sans dépendance technique.
• Les use cases sont orchestrés par l'application.
• L'infrastructure reste remplaçable.
• Les tests démontrent les invariants métier critiques.
• La solution se lance et se teste entièrement via CLI.

Cap final du module

• Industrialiser une base C# maintenable.
• Préparer un projet de Master soutenable dans le temps.
• Faire converger langage, architecture, outillage et qualité.