Application au package party

Statut documentaire : guide — voir Maturité et preuves.

Positionnement ontologique du package

Le package party appartient au niveau fondationnel. Sa responsabilité n’est pas de lister les acteurs d’un domaine particulier, mais de fournir une représentation stable de toute entité capable de jouer un rôle, d’entrer en relation, d’être identifiée, d’être contactée et d’être engagée dans d’autres structures métier. Cette responsabilité doit rester indépendante du secteur d’application. Dans un ERP pour centre de formation, un apprenant, un responsable légal, un enseignant, un établissement, un payeur ou un intervenant externe seront tous construits à partir de ce package, mais le package lui-même ne doit pas dépendre de ces spécialisations.

La première décision structurante consiste à faire de Party le concept racine. Une Party représente une entité actrice abstraite. Deux spécialisations structurelles sont généralement nécessaires : NaturalPerson et LegalEntity. Elles permettent de distinguer les attributs propres aux personnes physiques de ceux propres aux organisations sans dupliquer la logique commune. Cette spécialisation doit toutefois rester descriptive ; elle ne remplace pas les rôles métier, qui sont modélisés séparément.

Structuration interne recommandée

La deuxième décision consiste à modéliser le rôle comme un concept autonome. Une personne n’est pas intrinsèquement un apprenant, un salarié ou un tuteur ; elle joue un rôle dans un contexte. Le package doit donc introduire PartyRole comme mécanisme fondamental de contextualisation. Un rôle est porté par une party, possède un type, peut référencer un contexte, porte une validité temporelle et peut être primaire ou secondaire. Cette approche évite d’encoder les rôles sous forme de colonnes booléennes ou de sous-types rigides dès le niveau fondationnel.

La troisième décision porte sur les relations entre parties. Celles-ci ne doivent pas être réduites à des clés étrangères dispersées dans le système dès lors qu’elles possèdent une sémantique propre. Une relation parentale, une relation hiérarchique, une responsabilité financière, une affiliation ou une appartenance peuvent nécessiter une typologie, une direction, une période de validité, une source documentaire ou une relation entre rôles source et cible. Le package doit donc disposer d’un concept PartyRelationship explicite.

À ces briques s’ajoutent PartyIdentifier, ContactPoint, Address, PartyClassification et PartyStatusHistory. Les identifiants permettent de gérer plusieurs schémas d’identification, métier, légaux ou techniques, avec une gouvernance de primarité et de vérification. Les points de contact permettent de distinguer email, téléphone, messagerie, canal applicatif ou autre vecteur de communication sans les confondre avec une adresse postale. Les classifications permettent de rattacher une party à des taxonomies ou des segments sans altérer le noyau. L’historique de statut permet enfin de tracer les changements d’état sans effacer la mémoire du domaine.

Invariants du package

Le package party doit être gouverné par un ensemble réduit mais solide d’invariants. Une party doit posséder une identité stable et un statut cohérent. Un identifiant primaire actif doit être unique dans son schéma d’émission. Un rôle primaire ne doit pas être dupliqué pour un même type et un même contexte sur une période de validité chevauchante. Une relation active doit relier des parties existantes et non archivées, sauf si le modèle autorise explicitement les relations historiques vers des entités clôturées. Un point de contact marqué comme principal doit être unique par type d’usage lorsque cette règle est pertinente pour le métier.

Ces invariants doivent être exprimés au niveau du domaine et non reportés uniquement dans la base. La base de données peut renforcer certaines contraintes, mais elle ne remplace pas la sémantique métier. Il faut donc documenter clairement quels invariants sont vérifiés dans les actions, lesquels sont garantis par les agrégats et lesquels sont appuyés par des contraintes physiques.

Événements de domaine du package

Le package party doit publier des événements suffisamment stables pour être consommés par les packages transverses et sectoriels. La création d’une party, l’affectation d’un rôle, la création d’une relation, l’ajout ou la vérification d’un identifiant, la mise à jour d’un point de contact ou le changement de statut constituent des événements typiques. Ces événements ne doivent pas exposer la structure interne complète de l’agrégat, mais seulement les informations nécessaires à l’intégration. Les consommateurs ne doivent pas devenir dépendants d’une représentation technique interne ; ils doivent s’appuyer sur la sémantique publiée.

Dans un contexte éducatif, un package sectoriel pourra consommer un événement comme PartyRoleAssigned pour détecter qu’une personne devient Learner ou GuardianRole. Le package party n’a pas besoin de connaître cette spécialisation. Il lui suffit de publier correctement le fait qu’un rôle a été assigné, avec son type, son contexte et sa validité.

Projection technique et discipline de persistance

L’implémentation technique du package doit respecter cette structuration. Une classe XML principale peut porter le concept Party, tandis que d’autres classes ou concepts associés décrivent PartyRole, PartyRelationship, PartyIdentifier, ContactPoint et Address. Les facettes hypergraphes doivent exposer les attributs conceptuels utiles au domaine. Les facettes de persistance doivent matérialiser les identités, les clés de rattachement, les périodes de validité et les champs de recherche. Les collections doivent permettre d’explorer les rôles, relations, identifiants et moyens de contact sans contourner les actions métier.

Les actions métier recommandées sont typiquement AssignRole, LinkParty, AddIdentifier, AddContactPoint, ChangeStatus. Chacune doit être documentée avec ses préconditions, ses invariants, son comportement d’historisation et ses événements publiés. Cette approche évite que le package devienne une simple structure de stockage passive. Il reste ainsi un module de domaine fondationnel à part entière, directement exploitable par d’autres modules.

Intégration avec les niveaux supérieurs

Le package party ne doit pas être enrichi directement à chaque nouveau projet. Les spécialisations métiers doivent être portées par les packages de niveau supérieur. Un package education-party pourra définir Learner, Instructor, GuardianRole ou FinancialResponsibleRole comme spécialisations ou comme conventions basées sur PartyRole. Un package billing pourra exploiter les parties comme débiteurs, créanciers ou signataires sans altérer leur structure fondationnelle. Un package agreement pourra relier des parties à des engagements sans supposer de domaine particulier.

Cette discipline est le principal mécanisme de réutilisation. Elle permet d’éviter que le package party ne devienne un réceptacle universel de besoins locaux. Au contraire, il reste un noyau stable, simple en apparence mais suffisamment expressif pour supporter la plupart des scénarios d’entreprise lorsqu’il est combiné aux packages transverses et sectoriels adéquats.