På denne siden
To kunder har begge et felt som heter «active». For den ene betyr det at kunden har kjøpt noe de siste tolv månedene. For den andre betyr det at en tjenesteavtale fortsatt gjelder. En felles kobling kan flytte begge feltene riktig. En felles regel som behandler dem som samme forretningstilstand, kan være feil for én av dem. Dette er et tenkt eksempel, ikke en rapport fra en utrulling.
En samtale om felles plattformer og lokal utrulling beskriver en bedrift som gjenbruker mye av infrastrukturen sin, men fortsatt gjør betydelig arbeid i hvert kundemiljø. Prosenttallene i samtalen gjelder den bedriften. Det generelle arkitekturspørsmålet er hvor den felles teknikken slutter og den lokale betydningen begynner.
Skill transportkontrakten fra forretningskontrakten
En transportkontrakt kan si: Autentiser mot kilden, les endrede poster, bevar identifikatorer, prøv trygt igjen og vis feil. Disse delene kan bygges én gang og testes på nytt. De er verdifulle fordi hver integrasjon trenger en pålitelig vei for data.
En forretningskontrakt sier hvilken post som er fasit, hva en status betyr, når en handling er tillatt, og hvem som kan rette en feil.
- Felles transport identitet · nytt forsøk · hendelses-ID
leverer en gyldig hendelse
- Lokal regel betydning · samtykke · tidspunkt
avgjør om handling er tillatt
- Autorisert handling skriving · spor
registrerer resultatet
Forretningskontrakten avhenger av arbeidsflyten. Den kan bruke samme kilde og målsystem som hos en annen kunde, men kreve et annet svar.
Se på en kobling mellom butikk og e-postsystem. Plattformen kan ta imot hendelser, fjerne duplikater og lagre et spor. Den som eier arbeidsflyten, må definere om «subscribed» betyr tillatelse til et bestemt markedsføringsformål, om et kjøp stopper en påminnelse om handlekurven, og hvordan endret samtykke påvirker meldinger som allerede står i kø. Dette er ikke funksjoner i en kobling som kan gjettes fra feltnavn.
Den illustrerte Tajo-kartleggingen kopierer tre felt direkte. Legg merke til avgjørelsen som mangler: Ingen rad definerer markedsføringstillatelse. Gjenbruk av transporten sparer arbeid, men den ansvarlige for arbeidsflyten må fortsatt angi hvilken status som tillater hvilken handling. En tydelig feltkartlegging viser gapet uten å tette det.
Gå gjennom en synkronisering før den kjøres
Synkroniser kundeoppdateringer med e-postplattformen min.
Kundesynkronisering
| Kildefelt | Målfelt | Regel |
|---|---|---|
email | EMAIL | Direkte |
first_name | FIRSTNAME | Direkte |
last_name | LASTNAME | Direkte |
Syntetisk forhåndsvisning bestått
3 felt kartlagt · Ingen skriving til målsystemet
Illustrativ utforming basert på Tajos kartleggingsverktøy. En syntetisk forhåndsvisning og et lagret utkast aktiverer ikke en synkronisering.
| Felles lag | Lokalt lag |
|---|---|
| Autentisering og fornyelse av token | Hvem som får tilgang til denne arbeidsflyten |
| Transport av hendelser og nye forsøk | Hvilken hendelse som teller som en forretningsmessig overgang |
| Stabile identifikatorer og fjerning av duplikater | Hvilke poster som viser til samme virkelige kunde |
| Logging og mekanismer for gjenoppretting | Hvem som avgjør en omstridt tilstand, og hvordan |
| Validering av kontrakt | Hva feltverdiene betyr og når de får utløse en handling |
Tabellen viser en grense i utformingen, ikke en påstand om at alle løsninger kan deles så ryddig.
Gjenbruk bryter sammen når det skjuler uenighet
En generell plattform får ofte et nytt konfigurasjonsfelt for hvert unntak. Først ser det ut som om gjenbruket bevares. Senere kan ingen se om en innstilling er et teknisk valg, et juridisk krav eller en forretningsbeslutning. Den felles kjernen blir en fjernkontroll for valg den ikke eier.
Se etter en stabil betingelse som må holde. «La aldri samme kildehendelse få virkning to ganger på samme post i målsystemet» kan ligge i en felles motor. «Send en rabatt når en kunde blir aktiv» kan ikke deles før «aktiv», den tillatte målgruppen og reglene for tilbudet har eiere. Motoren kan utføre en godkjent regel, men bør ikke finne på regelen.
Det hjelper også med vedlikehold. Hvis et API endres, kan plattformteamet oppdatere koblingen og testene. Hvis definisjonen av en kvalifisert kunde endres, kan forretningseieren oppdatere regelen og testeksemplene uten å vente på en omskriving av transporten. En tydelig grense lar hver endring nå den som har myndighet over den.
Gjenbruk teknikken uten å viske ut meningen
Lokale regler kan koste ekstra. En plattform uten noen felles kontrakt blir en samling skreddersydde skript. Svaret er å finne teknikk som gjentas, før du gjør gjentatte betydninger til én abstraksjon. En godt utformet felles byggestein kan ta imot en typet betingelse, hendelsestid og handlingsgrense, mens den forretningsmessige definisjonen av betingelsen forblir lokal.
Grensen bør testes med virkelige tilfeller. Ta en vanlig hendelse, et duplikat, en sen rettelse og en tillatelse som er trukket tilbake. Spør hvilket lag som er ansvarlig for hvert svar. Hvis en feil ikke kan plasseres, skjuler abstraksjonen eierskap. Hvis en ny kunde tvinger en felles enum-type for «active» til å få flere ubeslektede betydninger, er den felles typen for bred.
Den tilhørende artikkelen om utrulling undersøker om en evne virker inne i en virkelig arbeidsflyt. Her spør vi hva som kan bygges én gang uten å viske ut hva arbeidsflyten betyr.
Grensesnittet mellom lagene bør være tydelig nok til å avvise en feil antakelse. En felles motor kan kreve hendelses-ID, tidspunkt i kilden, aktør og oppgitt formål før den godtar en forespørsel om handling. Den lokale arbeidsflyten kan levere regelen som avgjør om handlingen er tillatt. Hvis formålet mangler, bør motoren avvise forespørselen. Hvis regelen er tvetydig, må den lokale eieren avgjøre. Det bevarer gjenbruk uten å legge forretningsmyndighet i generell kode. Beskriv kontrakten med ett godkjent og ett avvist eksempel, og test begge hver gang et av lagene endres.
En kobling som kan gjenbrukes, bør gjøre lokal betydning enklere å uttrykke og tryggere å utføre. Den bør aldri få to forskjellige løfter til å se like ut bare fordi feltene har samme navn.
Ofte Stilte Spørsmål
Hva bør en integrasjonsplattform vanligvis gjenbruke?
Stabil teknikk som mønstre for autentisering, transport, idempotens, nye forsøk, logging og kontraktssjekker kan ofte deles når kravene faktisk er like.
Hva bør forbli spesifikt for en bedrift?
Betydningen av felt, hvilken kilde som er fasit, samtykkeregler, tidskrav og hvem som får handle på en status, må avklares for bedriften og arbeidsflyten.
Hvordan kan team teste grensen?
Prøv å beskrive en ny arbeidsflyt med delene som allerede finnes. Hvis det endrer forretningsbetydningen eller skjuler unntak i generelle innstillinger, la logikken være lokal og gjør grensesnittet tydelig.