La demande

La demande est l’unité durable de suivi d’une attente adressée au teneur de compte : une réclamation, une question, une instruction reçue par un canal quelconque. Elle se distingue de l’échange — le message immuable arrivé ou parti sur son canal — et du traitement métier, qui est exécuté ailleurs, par le domaine compétent.

La réception ne bloque jamais.

C’est le principe fondateur du cycle. Une demande dont on ignore l’auteur est reçue quand même, avec son canal d’origine et son instant de réception ; le demandeur se qualifie ensuite — déclaré, rapproché, vérifié, ou contesté. Rien n’est perdu au motif qu’on ne sait pas encore à qui l’attribuer.

stateDiagram-v2
  direction LR
  state "Reçue" as R
  state "Qualifiée" as Q
  state "En travail" as T
  state "Résolue" as S
  state "Clôturée" as C
  state "Annulée" as A
  [*] --> R : canal, réception — publie « demandeRecue »
  R --> Q : catégorie et priorité — publie « demandeQualifiee »
  Q --> T : affectée à une file — publie « demandeAffectee »
  T --> T : transférée, escaladée
  T --> S : résultat suffisant, ou décision motivée — publie « demandeResolue »
  S --> C : suivi terminé — publie « demandeCloturee »
  C --> T : réouverture motivée — publie « demandeRouverte »
  R --> A : annulation motivée, ou doublon d'une autre demande
  T --> A : annulation motivée, ou doublon d'une autre demande
  A --> [*]

Deux gardes tiennent la fin du cycle. On ne clôture jamais sans résolution, et jamais tant qu’un traitement requis est encore actif — la clôture fige alors les échéances et leurs dépassements. Et la réouverture est un ajout : l’histoire close demeure, le motif est exigé.

Ce qui arrive à une demande en cours de route

Elle se qualifie. Catégorie et priorité viennent d’une taxonomie versionnée. Une requalification ne déplace jamais l’événement qui fait courir les échéances, et une expression de mécontentement ne se reclasse pas pour échapper à un délai.

Elle se regroupe ou se dissocie. Deux demandes qui n’en font qu’une : la secondaire est marquée doublon, référence la principale et garde ses échanges ; la principale retient la contrainte la plus exigeante des deux. À l’inverse, une demande qui en contenait plusieurs se dissocie en demandes dérivées — la source reste consultable, les échanges sont rattachés explicitement, objets et échéances sont répartis.

Elle s’accroche à des objets métier. Un lien vers un objet d’un autre domaine porte une référence typée — domaine, type, identifiant — et sa finalité : l’objet est concerné, il fonde la demande, il en résulte, il en est la preuve, ou il est à corriger. L’état détaillé de l’objet n’est jamais importé ; on ne recopie pas ici ce qu’un autre domaine détient.

Elle porte des échéances. Une échéance est matérialisée en citant la règle, sa version, l’événement de départ et la version du calendrier. Elle s’annonce menacée quand un seuil est atteint, puis dépassée quand le délai est franchi — et le premier dépassement est immuable. Aucun dépassement n’est jamais supprimé.

Les traitements demandés aux autres domaines

Quand la demande appelle un acte métier, le domaine émet une commande canonique idempotente vers le domaine compétent, puis suit ce qu’il en advient.

stateDiagram-v2
  direction LR
  state "Demandé" as D
  state "Accepté" as A
  state "Rejeté" as J
  state "Résultat reçu" as R
  state "Régularisé" as G
  [*] --> D : commande émise — publie « traitementDemande »
  D --> A : le domaine cible accepte — publie « traitementAccepte »
  D --> J : rejet motivé — publie « traitementRejete »
  A --> R : résultat ou erreur — publie « resultatRecu »
  R --> G : résultat nouveau, lié au précédent — publie « resultatCorrige »
  J --> [*]
  G --> [*]

L’identifiant de commande porte l’idempotence : une nouvelle tentative technique le réutilise, une nouvelle intention métier en crée un nouveau, lié au précédent. Un résultat en erreur reste — la régularisation est un résultat nouveau qui cite celui qu’il corrige, jamais une réécriture.

La réponse

Une réponse cite ses sources dès le projet. Elle se valide selon la règle applicable, puis s’émet — le connecteur envoie, enregistre l’échange sortant et la preuve de remise. Une erreur d’envoi ultérieure ne ramène pas une réponse validée à l’état de brouillon : la validation est acquise.

Les faits publiés

Deux canaux, parce que les rythmes diffèrent.

relation-tiers.demandes-et-echanges.v1 — la vie de la demande et de ses messages : demandeRecue, demandeurIdentifie, demandeQualifiee, demandeAffectee, demandeTransferee, demandeEscaladee, objetRattache, objetDetache, echangeEnregistre, echangeRattache, echangeDetache, demandesRegroupees, demandeDissociee.

relation-tiers.traitements-et-reponses.v1 — ce que la demande déclenche et ce qui la solde : traitementDemande, traitementAccepte, traitementRejete, resultatRecu, resultatCorrige, echeanceCalculee, echeanceMenacee, echeanceDepassee, reponsePreparee, reponseValidee, reponseEnvoyee, reponseRemise, demandeResolue, demandeCloturee, demandeRouverte.

Ce que ces canaux ne publient jamais

Le contenu ne circule pas. Ni le sujet d’un message, ni son résumé, ni le nom des participants, ni une pièce jointe : les faits portent des références et des codes, et le contenu se lit par l’interface synchrone, sous habilitation et finalité. Un échange détaché l’est avec son motif et n’est jamais supprimé.

Garanties

Aux garanties communes aux événements, ce canal ajoute que l’ordre est garanti par entité, que le tenant est obligatoire dans l’enveloppe comme dans la partition de transport, et qu’un événement publié ne se supprime jamais : la correction est un fait nouveau qui cite celui qu’il corrige.

La structure exacte des messages est dans le contrat des événements publiés.