Na tej stronie
Dwie firmy korzystające z integracji mają pole nazwane „active”. W jednej oznacza ono zakup klienta w minionym roku. W drugiej ważną umowę o świadczenie usługi. Wspólny łącznik potrafi poprawnie przenieść oba pola. Wspólna reguła traktująca je jako ten sam stan biznesowy może pomylić się u jednego klienta. To ilustracyjny przykład, a nie relacja z wdrożenia.
Dyskusja o wspólnych platformach i lokalnym wdrażaniu opisuje firmę wykorzystującą znaczną część infrastruktury ponownie, ale nadal wykonującą istotną pracę w środowisku każdego klienta. Jej wartości procentowe dotyczą tej jednej firmy. Ogólne pytanie architektoniczne brzmi, gdzie kończy się wspólna mechanika, a zaczyna lokalne znaczenie.
Oddziel umowę transportową od biznesowej
Umowa transportowa może określać: uwierzytelnij się w źródle, czytaj zmienione rekordy, zachowuj identyfikatory, bezpiecznie ponawiaj i pokazuj awarie. Te zachowania można wdrożyć raz i testować wielokrotnie. Są cenne, bo każda integracja potrzebuje wiarygodnej drogi dla danych.
Umowa biznesowa określa, który rekord jest autorytatywny, co oznacza status, kiedy wolno działać i kto może poprawić pomyłkę.
- Wspólny transport tożsamość · ponowienie · ID zdarzenia
dostarcza poprawne zdarzenie
- Lokalna polityka znaczenie · zgoda · czas
decyduje o działaniu
- Uprawnione działanie zapis · audyt
utrwala wynik
Umowa biznesowa zależy od procesu. Może korzystać z tego samego źródła i celu co u innego klienta, a mimo to wymagać innej odpowiedzi.
Rozważ połączenie sklepu z systemem e-mailowym. Platforma może zapewnić przyjmowanie zdarzeń, deduplikację i ślad audytu. Właściciel procesu musi określić, czy „subscribed” oznacza zgodę na konkretny cel marketingowy, czy zakup wyklucza przypomnienie o koszyku i jak zmiana zgody wpływa na wiadomości już oczekujące. To nie są funkcje łącznika, które można wywnioskować z nazw pól.
Ilustrowane mapowanie Tajo kopiuje bezpośrednio trzy pola. Brakuje jednej decyzji: żaden wiersz nie definiuje zgody na marketing. Ponowne użycie mechanizmu przesyłania danych oszczędza pracę, ale osoba odpowiedzialna za proces musi określić, jaki status pozwala na jakie działanie. Przejrzyste mapowanie ujawnia tę lukę, lecz jej nie usuwa.
Sprawdź synchronizację przed uruchomieniem
Synchronizuj aktualizacje klientów z moją platformą emailową.
Synchronizacja klientów
| Pole źródłowe | Pole docelowe | Reguła |
|---|---|---|
email | EMAIL | Bezpośrednio |
first_name | FIRSTNAME | Bezpośrednio |
last_name | LASTNAME | Bezpośrednio |
Próba na danych syntetycznych zakończona powodzeniem
3 pola zmapowane · Bez zapisu w systemie docelowym
Ilustracyjny układ oparty na narzędziach mapowania Tajo. Próba na danych syntetycznych i zapisany projekt nie uruchamiają synchronizacji.
| Warstwa wspólna | Warstwa lokalna |
|---|---|
| Uwierzytelnianie i odświeżanie tokenów | Który podmiot może uzyskać dostęp do procesu |
| Transport zdarzeń i ponowienia | Które zdarzenie stanowi zmianę biznesową |
| Trwałe identyfikatory i deduplikacja | Które rekordy oznaczają tego samego klienta |
| Logowanie i narzędzia odzyskiwania | Kto i jak rozstrzyga sporny stan |
| Walidacja umowy | Co znaczą wartości pól i kiedy mogą wywołać działanie |
Tabela pokazuje granicę projektową, nie twierdzi, że każde wdrożenie da się równie czysto podzielić.
Ponowne użycie zawodzi, gdy ukrywa spór
Ogólna platforma często dostaje nowe pole konfiguracji dla każdego wyjątku. Na początku wydaje się to chronić możliwość ponownego użycia. Później nikt nie umie odróżnić, czy ustawienie jest opcją techniczną, ograniczeniem prawnym czy decyzją biznesową. Wspólne jądro staje się pilotem do wyborów, których nie powinno podejmować.
Szukaj stabilnego niezmiennika. „Nie stosuj tego samego zdarzenia źródłowego dwa razy do tego samego rekordu docelowego” może należeć do wspólnego silnika. „Wyślij rabat, gdy klient stanie się aktywny” nie może być wspólną regułą, dopóki „aktywny”, dozwolona grupa i polityka oferty nie mają właścicieli. Silnik może wykonywać zatwierdzoną politykę, ale nie powinien jej wymyślać.
To pomaga też w utrzymaniu. Jeśli API się zmienia, zespół platformy aktualizuje adapter i testy. Jeśli zmienia się definicja klienta uprawnionego do oferty, właściciel biznesowy aktualizuje politykę i przykłady testowe bez czekania na przebudowę transportu. Jasna granica kieruje każdą zmianę do osoby mającej do niej uprawnienie.
Wykorzystuj mechanikę ponownie bez spłaszczania znaczenia
Lokalne reguły kosztują. Platforma bez wspólnej umowy zamienia się w zbiór skryptów pisanych osobno. Lepiej rozpoznawać powtarzalne mechanizmy przed uogólnianiem powtarzalnych znaczeń. Dobrze zaprojektowany wspólny element może przyjąć typowany warunek, czas zdarzenia i limit działania, a biznesową definicję warunku pozostawić lokalnie.
Sprawdź granicę na rzeczywistych przypadkach. Weź zwykłe zdarzenie, duplikat, późną poprawkę i cofnięte uprawnienie. Zapytaj, która warstwa odpowiada za każdą reakcję. Jeśli nie da się przypisać awarii, abstrakcja ukrywa odpowiedzialność. Jeśli nowy klient zmusza wspólny enum „active” do obejmowania kilku niezwiązanych znaczeń, typ wspólny jest za szeroki.
Towarzyszący artykuł o różnicy między demo a wdrożeniem bada, czy dana możliwość działa w rzeczywistym procesie. Ten pyta, co można zbudować raz bez zacierania sensu tego procesu.
Interfejs między warstwami powinien umieć odrzucić błędne założenie. Wspólny silnik może wymagać identyfikatora zdarzenia, czasu źródła, podmiotu działającego i deklarowanego celu, zanim przyjmie żądanie działania. Lokalny proces może dostarczyć politykę określającą, czy działanie jest dozwolone. Jeśli brakuje celu, silnik powinien odmówić; jeśli polityka jest niejednoznaczna, lokalny właściciel musi to rozstrzygnąć. To praktyczny sposób na ponowne użycie bez oddawania uprawnienia biznesowego ogólnemu kodowi. Opisz umowę na jednym przyjętym i jednym odrzuconym przykładzie, a potem testuj oba przy każdej zmianie warstwy.
Łącznik nadający się do ponownego użycia powinien ułatwiać wyrażenie lokalnego znaczenia i bezpieczne wykonanie. Nie może sprawiać, że dwie różne obietnice wyglądają identycznie tylko dlatego, że ich pola mają tę samą nazwę.
Najczęściej Zadawane Pytania
Co platforma integracyjna zwykle może wykorzystywać ponownie?
Stabilne mechanizmy, takie jak wzorce uwierzytelniania, transport, idempotencja, ponowienia, logowanie i kontrole umów, często można współdzielić, jeśli wymagania naprawdę są takie same.
Co powinno pozostać właściwe dla danej firmy?
Znaczenie pól, autorytet źródła, zasady zgody, wymagania czasowe i to, kto może działać na podstawie statusu, należy ustalić dla tej firmy i procesu.
Jak zespół może sprawdzić tę granicę?
Spróbuj opisać nowy proces istniejącymi elementami. Jeśli zmienia to znaczenie biznesowe lub ukrywa wyjątki w ogólnej konfiguracji, zachowaj logikę lokalnie i jawnie opisz interfejs.