Sur cette page
Deux entreprises clientes possèdent chacune un champ nommé « actif ». Pour l’une, il signifie qu’une personne a acheté quelque chose au cours des douze derniers mois. Pour l’autre, qu’un contrat de service est en vigueur. Un connecteur commun peut déplacer correctement les deux champs. Une règle commune qui les interprète comme le même état métier peut être fausse pour l’une des entreprises. C’est un exemple illustratif, pas le récit d’un déploiement.
Une discussion sur les plateformes partagées et les déploiements locaux décrit une entreprise qui réutilise une grande part de son infrastructure tout en travaillant beaucoup dans l’environnement de chaque client. Ses pourcentages lui sont propres. La question architecturale générale est de savoir où s’arrête la mécanique partagée et où commence le sens local.
Séparez le contrat de transport du contrat métier
Un contrat de transport peut dire : s’authentifier auprès de la source, lire les dossiers modifiés, préserver les identifiants, reprendre sans danger et rendre les échecs visibles. Ces comportements peuvent être réalisés une fois et testés à répétition. Ils ont de la valeur parce que chaque intégration a besoin d’un trajet fiable pour les données.
Un contrat métier dit quel dossier fait autorité, ce que signifie un statut, quand une action est permise et qui peut réparer une erreur.
- Transport partagé identité · reprise · ID d’événement
livre un événement valide
- Politique locale sens · consentement · délai
autorise ou refuse l’action
- Action autorisée écriture · audit
consigne le résultat
Ce contrat métier dépend du processus. Deux clients peuvent avoir la même source et la même destination tout en exigeant des réponses différentes.
Prenez une connexion entre une boutique et un outil d’e-mail. La plateforme peut recevoir les événements, éliminer les doublons et garder une piste d’audit. Le responsable du processus doit définir si « abonné » signifie consentement pour un objectif marketing précis, si un achat bloque un rappel de panier et comment un changement de consentement affecte les messages déjà programmés. Ces questions ne se devinent pas en lisant le nom des champs du connecteur.
La correspondance Tajo illustrée ci-dessous copie directement trois champs. Une décision manque : aucune ligne ne définit l’autorisation de prospection. Réutiliser le transport épargne du travail, mais la personne responsable du processus doit préciser quel statut autorise quelle action. Une correspondance claire révèle ce manque sans le combler.
Examiner une synchronisation avant son lancement
Synchronisez les mises à jour clients avec ma plateforme email.
Synchronisation clients
| Champ source | Champ cible | Règle |
|---|---|---|
email | EMAIL | Directe |
first_name | FIRSTNAME | Directe |
last_name | LASTNAME | Directe |
Aperçu synthétique validé
3 champs associés · Aucune écriture dans la cible
Présentation illustrative fondée sur les outils de correspondance de Tajo. Un aperçu synthétique et un brouillon enregistré n'activent pas une synchronisation.
| Couche partagée | Couche locale |
|---|---|
| Authentification et renouvellement des jetons | Quelle identité peut accéder à ce processus |
| Transport des événements et reprises | Quel événement constitue une transition métier |
| Identifiants stables et dédoublonnage | Quels dossiers désignent la même personne réelle |
| Journaux et moyens de reprise | Qui résout un état contesté et comment |
| Validation des contrats | Ce que signifient les valeurs et quand elles peuvent déclencher une action |
Ce tableau pose une frontière de conception ; il ne prétend pas que toute réalisation se découpe aussi proprement.
La réutilisation échoue quand elle masque les désaccords
Une plateforme générique reçoit souvent un champ de configuration pour chaque exception. Au début, cela semble préserver la réutilisation. Plus tard, personne ne sait si un paramètre est une option technique, une contrainte juridique ou un choix commercial. Le cœur partagé devient une télécommande pour des décisions qu’il ne possède pas.
Cherchez une propriété stable. « Ne jamais appliquer deux fois le même événement source au même dossier de destination » peut appartenir à un moteur partagé. « Envoyer une remise quand un client devient actif » ne peut être commun tant que le sens d’« actif », le public autorisé et les règles de l’offre n’ont pas de responsables. Le moteur peut exécuter une politique approuvée, pas en inventer une.
Cela facilite l’entretien. Si une API change, l’équipe plateforme met à jour l’adaptateur et ses tests. Si la définition d’un client admissible change, la personne responsable du métier modifie la politique et les cas de test sans attendre une refonte du transport. Une frontière nette dirige chaque changement vers l’autorité qui lui correspond.
Réutilisez la mécanique sans effacer le sens
Certaines règles locales ajoutent du coût. Une plateforme sans contrat réutilisable devient un ensemble de scripts sur mesure. La réponse est d’identifier les mécanismes répétés avant de généraliser les significations répétées. Un composant partagé peut accepter une condition typée, une date d’événement et une limite d’action tout en laissant la définition métier de la condition au processus local.
Testez la frontière sur des cas réels. Prenez un événement normal, un doublon, une correction tardive et un droit retiré. Demandez quelle couche répond à chacun. Si personne ne peut attribuer l’échec, l’abstraction cache la responsabilité. Si un nouveau client force l’énumération commune « actif » à recevoir plusieurs sens sans rapport, le type partagé est trop large.
L’article complémentaire sur le déploiement examine si une capacité fonctionne dans un processus réel. Celui-ci demande ce qui peut être construit une seule fois sans effacer le sens du processus.
L’interface entre couches doit être assez explicite pour refuser une mauvaise hypothèse. Un moteur commun peut exiger un identifiant d’événement, une date source, une identité agissante et une finalité déclarée avant d’accepter une demande d’action. Le processus local fournit la politique qui décide si cette action est permise. Sans finalité, le moteur doit refuser ; si la politique est ambiguë, le responsable local doit trancher. C’est une façon pratique de préserver la réutilisation sans céder l’autorité métier au code générique. Documentez le contrat avec un exemple accepté et un exemple rejeté, puis testez les deux chaque fois que l’une des couches change.
Un connecteur réutilisable devrait faciliter l’expression du sens local et son exécution sûre. Il ne devrait jamais rendre identiques deux promesses différentes au seul motif que leurs champs portent le même nom.
Questions fréquemment posées
Que peut généralement réutiliser une plateforme d’intégration ?
Les mécanismes stables, comme les modèles d’authentification, le transport, l’idempotence, les reprises, les journaux et les contrôles de contrat, peuvent être partagés quand les besoins sous-jacents concordent.
Que faut-il laisser propre à chaque entreprise ?
Le sens des champs, l’autorité de la source, les règles de consentement, les contraintes de temps et le droit d’agir à partir d’un statut doivent être établis pour cette entreprise et ce processus.
Comment tester cette frontière ?
Essayez d’exprimer un nouveau processus avec les composants existants. Si cela change le sens métier ou cache des exceptions dans une configuration générique, gardez cette logique localement et explicitez l’interface.