Adaptabilité opérationnelle
Adapter un parcours à un pays, un segment ou une politique de risque ne signifie pas cacher ces différences derrière une sélection automatique. Ormuz privilégie un modèle explicite : le contexte est typé, la politique est versionnée, les routes restent visibles et chaque capacité externe est choisie par une configuration connue.
Principe : mutualiser ce qui est vraiment commun
Deux marchés peuvent partager la collecte des informations, les objets métier produits et le résultat attendu, tout en divergeant sur une vérification, un seuil ou un service externe. Conservez ces éléments communs dans le même processus lorsque cela rend le parcours plus lisible ; créez des branches ou des artefacts distincts lorsque leurs contrats métier deviennent réellement différents.
Le contexte alimente une politique explicite. Les branches peuvent employer des configurations différentes tout en convergeant vers le même contrat métier Ormuz.
Porter le contexte sans créer un second modèle métier
Commencez par les données déjà canoniques : l’entreprise, ses groupes, les objets commerciaux, les résultats de conformité ou les projections de crédit. Un processus peut également recevoir un input dédié lorsqu’une information de contexte ne correspond pas à un objet Ormuz existant.
Les bindings et expressions peuvent lire input, les sorties garanties des nodes précédents,vars et env. Une variable d’environnement convient à une configuration qui diffère entre sandbox et production ou entre marchands ; elle n’est pas un substitut à une donnée métier qui devrait vivre sur un objet canonique.
Voir Entrées, sorties et bindings et Principes du modèle métier.
Choisir entre routage et Decision
| Besoin | Préférez | Pourquoi |
|---|---|---|
| Condition locale simple et directement lisible dans le graphe | Routeur Core | Le choix reste proche des branches qu’il contrôle. |
| Politique réutilisable, testable et versionnée séparément | Decision | La logique déterministe possède son propre contrat, ses révisions et ses Runs. |
| Cas ambigu nécessitant analyse contextuelle et capacités bornées | Agent | L’activité possède un contrat typé, des tools explicites et des guardrails ; le processus reste responsable du traitement du résultat. |
Choisir les capacités externes explicitement
Les extensions déclarent les nodes, événements et objets externes qu’elles fournissent. Un node d’extension référence une configuration compatible ; celle-ci fixe notamment le compte provider et son environnement. Le processus peut donc utiliser deux configurations différentes sur deux branches sans modifier son modèle d’objets Ormuz.
Ce découplage ne signifie pas que toutes les extensions sont interchangeables. Deux providers peuvent exposer des contrats de nodes ou des résultats différents. Factorisez le parcours seulement jusqu’au point où leurs garanties restent réellement comparables, puis normalisez le résultat métier explicitement si votre design le nécessite.
Consultez Intégrations pour les capacités réellement disponibles et leur statut.
Segmenter sans dupliquer la politique partout
Les groupes d’entreprises offrent une identité métier durable pour une population : canal commercial, portefeuille géré, segment interne ou autre regroupement décidé par le marchand. Le node check_company_group_membership route explicitement selon l’appartenance d’une entreprise.
Pour une politique plus riche, transmettez les informations nécessaires à une Decision plutôt que de recopier les mêmes seuils dans plusieurs routeurs. La Decision peut alors évoluer indépendamment du processus tout en restant déterministe et testable.
| Variation | Où la porter |
|---|---|
| Un seuil ou une règle varie par contexte | Decision — Versionnez la politique indépendamment du graphe et évaluez-la avec des inputs typés. |
| Deux parcours réellement différents doivent diverger | Routage du processus — Utilisez une route explicite et rendez les branches visibles dans le graphe. |
| Une population métier doit recevoir un traitement particulier | Company Group — Regroupez les entreprises puis testez l’appartenance avec check_company_group_membership. |
| Une valeur de configuration change entre environnements | Variable d’environnement — Référencez env.<nom> dans un binding ou une expression au lieu de dupliquer le processus. |
| Une capacité externe diffère selon le cas | Configuration d’extension + branche explicite — Chaque node d’extension utilise la configuration sélectionnée pour cette branche ; Ormuz ne choisit pas silencieusement un provider à partir d’un pays ou d’un segment. |
Faire évoluer sans ambiguïté
Une adaptation opérationnelle saine sépare les axes qui n’ont pas le même cycle de vie. Le processus porte l’enchaînement ; une Decision porte une politique déterministe ; une révision d’Agent porte ses activités et son autorité ; une configuration d’extension porte l’accès au service externe. Cette séparation évite qu’un changement de seuil oblige à redessiner le graphe ou qu’un changement de provider modifie silencieusement une règle métier.
- Testez chaque route importante avec un contexte représentatif.
- Épinglez les dépendances requises lorsque le contrat de déploiement l’exige.
- Gardez les différences sandbox/production dans les ressources et variables prévues pour l’environnement.
- Observez le résultat métier final, pas seulement la réussite technique de l’appel provider.