Na ovoj stranici
Dvije tvrtke u podacima svojih kupaca imaju polje „aktivan”. Za jednu znači da je kupac nešto kupio tijekom protekle godine. Za drugu znači da još vrijedi ugovor o usluzi. Zajednički konektor može ispravno prenijeti oba polja. Zajedničko pravilo koje ih tretira kao isto poslovno stanje može biti pogrešno za jednu tvrtku. Ovo je zamišljen primjer, a ne izvješće o uvođenju.
Rasprava o zajedničkim platformama i lokalnom uvođenju opisuje tvrtku koja ponovno koristi velik dio infrastrukture, ali i dalje mnogo radi u okruženju svakog kupca. Navedeni postoci odnose se samo na nju. Opće arhitekturno pitanje glasi gdje zajednička mehanika završava, a lokalno značenje počinje.
Odvojite ugovor o prijenosu od poslovnog ugovora
Ugovor o prijenosu može navesti: autentificirati se na izvor, čitati promijenjene zapise, sačuvati identifikatore, sigurno ponavljati pokušaje i prikazivati kvarove. Takva se ponašanja mogu jednom provesti i iznova testirati. Vrijedna su jer svaka integracija treba pouzdan put za podatke.
Poslovni ugovor kaže koji je zapis mjerodavan, što znači status, kada je radnja dopuštena i tko može ispraviti pogrešku.
- Zajednički prijenos identitet · ponavljanje · ID događaja
dostavlja valjan događaj
- Lokalna pravila značenje · privola · vrijeme
odlučuju je li radnja dopuštena
- Dopuštena radnja upis · revizija
bilježi ishod
Taj poslovni ugovor ovisi o tijeku rada. Može koristiti isti izvor i odredište kao ugovor druge tvrtke, a ipak tražiti drukčiji odgovor.
Pogledajte vezu trgovine i sustava e-pošte. Platforma može pružiti primitak događaja, uklanjanje duplikata i revizijski trag. Vlasnik tijeka rada mora odrediti znači li „pretplaćen” dopuštenje za određenu marketinšku svrhu, zaustavlja li kupnja podsjetnik na košaricu i kako promjena privole utječe na poruke koje već čekaju. To nisu značajke konektora koje se mogu pogoditi iz naziva polja.
Ilustrirana mapa Tajo u nastavku izravno kopira tri polja. Primijetite odluku koja nedostaje: nijedan red ne definira dopuštenje za marketing. Ponovna upotreba prijenosa štedi posao, ali vlasnik tijeka rada i dalje mora odrediti koji status dopušta koju radnju. Uredna mapa polja otkriva taj nedostatak, ali ga ne rješava.
Pregledajte sinkronizaciju prije pokretanja
Sinkronizirajte promjene podataka kupaca s mojom platformom za e-poštu.
Sinkronizacija kupaca
| Izvorno polje | Odredišno polje | Pravilo |
|---|---|---|
email | EMAIL | Izravno |
first_name | FIRSTNAME | Izravno |
last_name | LASTNAME | Izravno |
Sintetički pregled je uspio
Mapirana su 3 polja · Nema upisa u odredište
Ilustrativni prikaz temelji se na alatima Tajo za mapiranje. Sintetički pregled i spremljena skica ne aktiviraju sinkronizaciju.
| Zajednički sloj | Lokalni sloj |
|---|---|
| Autentifikacija i obnova tokena | Koji subjekt smije pristupiti ovom tijeku rada |
| Prijenos događaja i ponavljanja | Koji događaj predstavlja poslovnu promjenu |
| Stabilni identifikatori i uklanjanje duplikata | Koji zapisi označavaju istog stvarnog kupca |
| Zapisi i načini oporavka | Tko i kako razrješava sporno stanje |
| Provjera ugovora | Što znače vrijednosti polja i kada smiju pokrenuti radnju |
Tablica označava projektnu granicu, a ne tvrdi da se sve izvedbe mogu ovako uredno razdijeliti.
Ponovna uporaba puca kada skriva neslaganje
Opća platforma često dobiva novo polje postavki za svaku iznimku. U početku se čini da to čuva ponovnu uporabu. Poslije nitko ne zna je li postavka tehnička mogućnost, pravno ograničenje ili poslovna odluka. Zajednička jezgra postaje daljinski upravljač za odluke koje joj ne pripadaju.
Tražite stabilno nepromjenjivo pravilo. „Nikada dvaput ne primijeni isti izvorni događaj na isti odredišni zapis” može živjeti u zajedničkom mehanizmu. „Pošalji popust kada kupac postane aktivan” ne može biti zajedničko dok „aktivan”, dopuštena publika i pravilo ponude nemaju vlasnike. Mehanizam može izvršiti odobreno pravilo, ali ga ne smije izmišljati.
To pomaže i održavanju. Ako se API promijeni, tim platforme može ažurirati prilagodnik i testove. Ako se promijeni definicija kupca kojem je ponuda dopuštena, poslovni vlasnik može ažurirati pravilo i testne primjere bez prepisivanja prijenosa. Jasna granica vodi svaku promjenu osobi koja ima ovlast nad njom.
Ponovno koristite mehaniku bez brisanja značenja
Neka lokalna pravila zaista dodaju trošak. Platforma bez ugovora koji se mogu ponovno koristiti postaje zbirka posebnih skripti. Rješenje je otkriti ponavljajuće mehanizme prije izdvajanja ponavljajućih značenja. Dobro oblikovana zajednička sastavnica može prihvatiti tipizirani uvjet, vrijeme događaja i ograničenje radnje, a poslovnu definiciju uvjeta ostaviti lokalno.
Granicu provjerite na stvarnim slučajevima. Uzmite običan događaj, duplikat, zakašnjeli ispravak i opozvano dopuštenje. Pitajte koji sloj odgovara na svaki od njih. Ako se kvar ne može pripisati sloju, apstrakcija skriva vlasništvo. Ako novi kupac prisili zajedničku vrijednost „aktivan” da dobije više nepovezanih tumačenja, zajednički je tip preširok.
Povezani članak o uvođenju ispituje radi li mogućnost unutar stvarnog tijeka. Ovaj pita što se može izgraditi jednom, a da se ne izbriše značenje tog tijeka.
Sučelje između slojeva treba biti dovoljno jasno da odbije lošu pretpostavku. Zajednički mehanizam može prije prihvaćanja zahtjeva za radnju tražiti ID događaja, izvorno vrijeme, subjekt i deklariranu svrhu. Lokalni tijek može dati pravilo koje odlučuje je li radnja dopuštena. Ako svrha nedostaje, mehanizam treba odbiti zahtjev; ako je pravilo nejasno, lokalni vlasnik ga mora razriješiti. Tako se ponovna uporaba čuva bez prijenosa poslovne ovlasti na opći kod. Ugovor opišite jednim prihvaćenim i jednim odbijenim primjerom, pa testirajte oba pri svakoj promjeni bilo kojeg sloja.
Konektor koji se može ponovno koristiti treba olakšati izražavanje lokalnog značenja i sigurnije ga provoditi. Nikada ne treba učiniti da dva različita obećanja izgledaju jednako samo zato što im polja imaju isto ime.
Često postavljana pitanja
Što integracijska platforma obično treba ponovno koristiti?
Stabilna mehanika poput obrazaca autentifikacije, prijenosa, idempotentnosti, ponavljanja, zapisivanja i provjere ugovora često može biti zajednička ako se temeljni zahtjevi podudaraju.
Što treba ostati posebno za tvrtku?
Značenje polja, mjerodavnost izvora, pravila privole, vremenski zahtjevi i tko smije djelovati na određeni status moraju se utvrditi za tu tvrtku i taj tijek rada.
Kako timovi mogu provjeriti granicu?
Pokušajte novi tijek izraziti postojećim osnovnim sastavnicama. Ako se time mijenja poslovno značenje ili skrivaju iznimke u općim postavkama, zadržite pravilo lokalno i jasno definirajte sučelje.