Na této stránce
Dva zákazníci mají pole nazvané „active“. Pro jednoho znamená nákup v posledním roce. Pro druhého platnou smlouvu o službě. Společný konektor může obě pole přesunout správně. Společné pravidlo, které je považuje za stejný obchodní stav, se může u jednoho zákazníka mýlit. To je ilustrativní příklad, ne zpráva z nasazení.
Diskuse o společných platformách a místním nasazení popisuje firmu, která opakovaně používá mnoho své infrastruktury, ale stále vykonává podstatnou práci v prostředí každého zákazníka. Její procenta jsou specifická pro tuto firmu. Obecnou architektonickou otázkou je, kde končí společná mechanika a začíná místní význam.
Oddělte technickou specifikaci přenosu od pravidel obchodního významu
Technická specifikace přenosu může říkat: ověřte se u zdroje, čtěte změněné záznamy, zachovávejte identifikátory, bezpečně opakujte a ukazujte selhání. Toto chování lze implementovat jednou a opakovaně testovat. Každá integrace totiž potřebuje důvěryhodnou cestu pro data.
Pravidla obchodního významu určují autoritativní záznam, význam stavu, kdy je akce povolená a kdo smí opravit chybu.
- Společný transport identita · opakování · ID události
doručí platnou událost
- Místní pravidlo význam · souhlas · čas
rozhodne o povolení akce
- Oprávněná akce zápis · audit
zaznamená výsledek
Pravidla obchodního významu závisí na postupu. Může používat stejný zdroj i cíl jako jiný zákazník a přesto vyžadovat jinou odpověď.
Uvažujte propojení obchodu s e-mailovým systémem. Platforma může zajistit příjem událostí, deduplikaci a auditní stopu. Vlastník postupu musí určit, zda „subscribed“ znamená oprávnění pro určitý marketingový účel, zda nákup vyřadí připomínku košíku a jak změna souhlasu ovlivní zprávy již čekající na odeslání. To nejsou vlastnosti konektoru, které lze uhodnout z názvů polí.
Ilustrovaná mapa Tajo níže přímo kopíruje tři pole. Všimněte si chybějícího rozhodnutí: žádný řádek nedefinuje souhlas s marketingem. Opětovné použití přenosu šetří práci, ale vlastník postupu musí určit, který stav dovoluje kterou akci. Úhledná mapa polí mezeru ukáže, nevyřeší ji.
Zkontrolujte synchronizaci před spuštěním
Synchronizujte změny zákazníků s mou e-mailovou platformou.
Synchronizace zákazníků
| Zdrojové pole | Cílové pole | Pravidlo |
|---|---|---|
email | EMAIL | Přímo |
first_name | FIRSTNAME | Přímo |
last_name | LASTNAME | Přímo |
Syntetický náhled prošel
Namapována 3 pole · Žádný zápis do cílové služby
Ilustrační uspořádání vychází z nástrojů Tajo pro mapování. Syntetický náhled ani uložený koncept synchronizaci neaktivují.
| Společná vrstva | Místní vrstva |
|---|---|
| Ověřování a obnova tokenů | Kdo smí přistupovat k tomuto postupu |
| Transport událostí a opakování | Která událost znamená obchodní změnu |
| Stabilní identifikátory a deduplikace | Které záznamy patří stejnému skutečnému zákazníkovi |
| Logování a cesta obnovy | Kdo a jak řeší sporný stav |
| Ověření technické specifikace | Co znamenají hodnoty polí a kdy smějí spustit akci |
Tabulka je hranicí návrhu, ne tvrzením, že každou implementaci lze tak čistě rozdělit.
Sdílení selhává, když skrývá neshodu
Obecná platforma často získá konfigurační pole pro každou výjimku. Zpočátku to vypadá jako zachování opakovaného využití. Později už nikdo nepozná, zda nastavení představuje technickou možnost, právní omezení nebo obchodní rozhodnutí. Společné jádro se stane dálkovým ovladačem voleb, které nevlastní.
Hledejte stabilní invariant. „Nepoužijte stejnou zdrojovou událost dvakrát pro stejný cílový záznam“ může žít ve společném jádru. „Pošlete slevu, když se zákazník stane aktivním“ nelze sdílet, dokud „aktivní“, povolené publikum a pravidlo nabídky nemají vlastníky. Jádro může provést schválené pravidlo, nesmí je vymyslet.
Pomáhá to i údržbě. Změní-li se API, platformový tým upraví adaptér a testy. Změní-li se definice způsobilého zákazníka, obchodní vlastník upraví pravidlo a testovací příklady bez čekání na přepis transportu. Jasná hranice vede každou změnu k člověku s příslušným oprávněním.
Sdílejte mechaniku bez zploštění významu
Některá místní pravidla stojí práci. Platforma bez společné technické specifikace se změní v soubor skriptů na zakázku. Řešením je najít opakované mechanismy před zobecňováním opakovaných významů. Dobře navržený společný prvek může přijmout typovanou podmínku, čas události a limit akce, zatímco obchodní definice podmínky zůstane místní.
Hranici testujte skutečnými případy. Vezměte běžnou událost, duplikát, pozdní opravu a odebrané oprávnění. Ptejte se, která vrstva odpovídá za každou reakci. Pokud selhání nejde přiřadit, abstrakce skrývá odpovědnost. Pokud nový zákazník nutí společný výčtový typ „active“ nést několik nesouvisejících významů, sdílený typ je příliš široký.
Související článek o rozdílu mezi demem a nasazením zkoumá, zda schopnost funguje v živém postupu. Tento se ptá, co lze vybudovat jednou, aniž se vymaže význam postupu.
Rozhraní mezi vrstvami má umět odmítnout špatný předpoklad. Společné jádro může před přijetím žádosti o akci vyžadovat ID události, čas zdroje, jednající subjekt a deklarovaný účel. Místní postup může dodat pravidlo rozhodující, zda je akce povolená. Pokud účel chybí, jádro má odmítnout; je-li pravidlo nejednoznačné, místní vlastník musí rozhodnout. To je praktický způsob sdílení bez předání obchodní pravomoci obecnému kódu. Rozhraní zdokumentujte jedním přijatým a jedním odmítnutým příkladem a oba testujte při změně kterékoli vrstvy.
Opakovaně použitelný konektor má usnadnit vyjádření místního významu a jeho bezpečné provedení. Nikdy nemá nechat dva odlišné sliby vypadat stejně jen proto, že jejich pole mají stejný název.
Často Kladené Otázky
Co má integrační platforma obvykle používat opakovaně?
Stabilní mechaniku, například vzorce ověřování, transport, idempotenci, opakování, logování a kontroly technických specifikací, lze často sdílet, pokud se požadavky skutečně shodují.
Co musí zůstat specifické pro firmu?
Význam polí, autoritu zdroje, pravidla souhlasu, časové požadavky a to, kdo smí jednat na základě stavu, je třeba určit pro konkrétní firmu a postup.
Jak tým hranici otestuje?
Zkuste nový postup vyjádřit stávajícími prvky. Pokud tím změníte obchodní význam nebo skryjete výjimky v obecné konfiguraci, nechte logiku místní a rozhraní popište výslovně.