Application du Domain-Driven Design (DDD) pour modéliser une application de gestion hospitalière

```html

Application du Domain-Driven Design (DDD) pour modéliser une application de gestion hospitalière

La modélisation d’une application de gestion hospitalière exige de concilier de nombreuses contraintes : sécurité des données, complexité métier, traçabilité des actes, gestion des rôles, exigences réglementaires et évolution constante des processus de soins. Le Domain-Driven Design (DDD) aide à structurer l’approche logicielle autour du domaine métier, en réduisant l’écart entre le vocabulaire des équipes (métiers, paramédical, administratifs) et le code.

Pourquoi le DDD est pertinent en contexte hospitalier

Dans un hôpital, les règles métier sont nombreuses et fortement interconnectées : planification des consultations, admission, prescriptions, gestion des lits, urgences, priorisation, facturation et archivage. Une conception centrée uniquement sur la technologie conduit souvent à des modèles “ancrés en base” difficiles à faire évoluer.

Le DDD propose une méthode pour :

• Créer un langage commun entre équipes techniques et métier.
• Isoler les sous-domaines à complexité et cycles de vie différents.
• Encapsuler les règles métier dans des objets cohérents.
• Gérer correctement les invariants (ex. : une prescription doit respecter des règles de validité).
• Contrôler les interactions via des limites explicites (bounded contexts).

Découpage du domaine : bounded contexts et sous-domaines

La première étape consiste à identifier des bounded contexts, c’est-à-dire des périmètres où le modèle métier est cohérent et où les règles ne changent pas selon le contexte.

Exemples de bounded contexts

Contexte “Admission & Parcours”

• Admission, transfert, sortie.
• État clinique administratif (en attente, en cours, clôturé).
• Contraintes liées au parcours patient.

Contexte “Planification & Ressources”

• Gestion des agendas, plages opératoires, contraintes de capacité.
• Rattachement aux ressources (salles, lits, praticiens).
• Optimisation des contraintes (priorités, indisponibilités).

Contexte “Prescription & Traitements”

• Prescriptions, médicaments, posologies, renouvellements.
• Règles de validité (durée, intervalles, non-chevauchement).
• Traçabilité des modifications et validations.

Contexte “Facturation & Paiement”

• Génération des actes, remboursement, factures.
• Règles de calcul, statuts et justificatifs.
• Contrôle des montants et audit.

Chaque contexte peut utiliser sa propre représentation. Lorsqu’un même concept apparaît différemment (par exemple “acte” ou “séjour”), le DDD recommande de clarifier les différences de sens entre contextes.

Modélisation avec les concepts DDD

Entités, valeurs et agrégats

Les entités portent une identité qui persiste dans le temps (ex. Patient, Consultation). Les objets valeur décrivent des concepts immuables (ex. Adresse, Période, Montant). Les agrégats regroupent un ensemble cohérent d’objets autour d’une racine, garantissant des invariants.

Exemple : Agrégat “Prescription”

Une prescription exige des règles d’intégrité strictes : un traitement peut être refusé si le patient n’est pas éligible, ou si la période de validité chevauche une autre prescription non compatible.

Prescription (Aggregate Root) - id - patientId - items (ligne(s) de traitement) - periodeValidite - statut (Draft, Validated, Suspended) - methods: - valider() - suspendre(motif) - ajouterItem(medicament, posologie, regles)

Le code d’accès doit rester cohérent : les invariants sont contrôlés au niveau de la racine d’agrégat. Les modifications indirectes sont évitées (ou encadrées) pour ne pas casser la cohérence.

Gestion des règles métier : invariants et services de domaine

Invariants au cœur du modèle

Les invariants sont des règles qui doivent toujours rester vraies. En hospitalier, un exemple typique est la cohérence entre statut du parcours et actions possibles. Une sortie ne doit pas être déclenchée si des étapes obligatoires ne sont pas finalisées.

Services de domaine

Lorsque certaines règles nécessitent plus qu’un seul agrégat (ou des opérations qui ne rentrent pas naturellement dans l’agrégat), des services de domaine peuvent orchestrer les décisions. Ils encapsulent le “pourquoi”, sans devenir des contrôleurs applicatifs.

ServiceDeDomaine : QualificationEligibilitePatient - method: estEligible(patientId, traitement, periode) -> bool - sources: politiques de soins, historiques, contraintes

Stratégie d’intégration : bounded contexts, événements et commandes

Anti-corruption layer (ACL)

Les systèmes hospitaliers interagissent souvent avec des systèmes existants : SIH historiques, référentiels externes, outils d’imagerie, etc. Pour éviter de contaminer le modèle, un Anti-Corruption Layer transforme les données entrantes/sortantes afin de préserver le sens interne du contexte.

Événements de domaine

Les événements permettent de relier les contextes via des changements significatifs. Par exemple, lorsqu’une prescription est validée, d’autres contextes peuvent réagir : planification des dispenses, mise à jour de la traçabilité, préparation pharmaceutique.

DomainEvent : PrescriptionValidated - prescriptionId - patientId - validFrom - itemsSummary

Commande et orchestration

Les demandes d’action s’expriment souvent sous forme de commandes. Une commande déclenche une décision dans un contexte (par exemple “PlanifierConsultation”). Les workflows trans-contextes peuvent utiliser des process managers ou une orchestration asynchrone.

Architecture applicative recommandée

Couches et responsabilité

Une architecture DDD standard sépare :

• Couche Domaine : entités, objets valeur, agrégats, services de domaine, invariants, événements.
• Couche Application : cas d’usage, orchestrations, gestion des transactions, exécution des commandes.
• Couche Infrastructure : persistance, connecteurs API, implémentations techniques (ORM, bus d’événements).

Exemple de cas d’usage applicatif

UseCase : ValiderPrescriptionCommandHandler - charge l’agrégat Prescription - appelle prescription.valider() - publie l’événement PrescriptionValidated - persiste les changements

Cette séparation limite la logique métier dans le domaine et empêche la couche application de devenir un “second domaine” incontrôlé.

Modélisation du langage : Ubiquitous Language

Alignement sémantique

Le langage omniprésent (Ubiquitous Language) est un livrable vivant. Il décrit des termes stabilisés : “séjour”, “consultation”, “prescription”, “dispensation”, “lot”, “statut”, “prescripteur”.

Chaque terme est documenté avec un sens et un périmètre. En cas de divergence, les bounded contexts et l’ACL doivent la clarifier.

Qualité, évolutivité et tests

Tests orientés modèle

Le DDD facilite des tests robustes : tests de domaine (invariants, transitions d’état), tests applicatifs (cas d’usage, orchestration), tests d’intégration (contrats d’événements, connecteurs).

Évolution contrôlée

Les hôpitaux font évoluer leurs pratiques. Un modèle DDD bien structuré permet de modifier un bounded context sans impacter l’ensemble, à condition de maintenir des contrats clairs (événements, DTO, ACL).

Conclusion

Le Domain-Driven Design constitue une approche efficace pour modéliser une application de gestion hospitalière en alignant la conception logicielle sur le domaine métier. En découpant le système en bounded contexts, en renforçant la cohérence via les agrégats et les invariants, puis en orchestrant les interactions par événements et couches anti-corruption, l’application gagne en clarté, maintenabilité et capacité d’évolution.