Scenario et modele de domaine

Statut documentaire : tutorial — voir Maturité et preuves.

Scenario

Un client soumet une demande qui doit etre evaluee avant approbation. L'application represente le client, la demande, les indicateurs, le processus de revue et la decision finale. Une verification externe ou une explication IA peut etre asynchrone, alors que des validations simples peuvent rester synchrones.

Concepts principaux

Utiliser des identifiants appartenant au projet, par exemple :

risk#customer
risk#request
risk#indicator
risk#review_process
risk#decision

Le namespace exact appartient au projet. La regle importante est une identite conceptuelle stable par signification.

Roles minimaux

Customer porte l'identite et les donnees descriptives. RiskRequest reference un client, une date de creation et un etat de cycle de vie. RiskIndicator appartient a une demande et porte une observation typee. RiskDecision enregistre le resultat et son explication. RiskReviewProcess coordonne les travaux entre ces objets.

Facettes

Modeliser d'abord la structure conceptuelle dans la facette hypergraphe. Ajouter ensuite la persistance comme projection de cette structure, avec des role paths explicites. Ne pas laisser la structure des tables definir l'ontologie.

Assemblage

Le module suit la chaine habituelle :

configuration application
  -> package
  -> manifest de classes
  -> modeles
  -> metadonnees Runtime
  -> ClassItems/ObjectItems executables

Commencer avec le Runtime en memoire jusqu'a resolution des cinq concepts par identifiant. Ajouter la persistance apres validation du chargement.