На тази страница
Двама клиенти имат поле с име „активен“. За единия то значи, че клиентът е купил нещо през последните дванадесет месеца. За другия означава, че договорът за услуга още е в сила. Общ конектор може да премести правилно и двете полета. Общо правило, което ги третира като едно и също бизнес състояние, може да е грешно за единия. Това е илюстративен пример, не разказ от внедряване.
Разговор за общи платформи и местно внедряване описва компания, която използва повторно голяма част от инфраструктурата си, но все пак върши значителна работа във всяка клиентска среда. Процентите ѝ са специфични за компанията. Общият архитектурен въпрос е къде спират общите механизми и започва местният смисъл.
Отделете договора за транспорт от бизнес договора
Договор за транспорт може да казва: удостоверете се пред източника, прочетете променените записи, пазете идентификаторите, повтаряйте безопасно и показвайте провалите. Това поведение може да се реализира веднъж и да се тества многократно. Ценно е, защото всяка интеграция се нуждае от надежден път за данни.
Бизнес договорът казва кой запис е авторитетен, какво значи даден статус, кога действие е разрешено и кой може да поправи грешка.
- Общ транспорт идентичност · повторение · ID събитие
доставя валидно събитие
- Местна политика смисъл · съгласие · време
решава дали действие е позволено
- Разрешено действие запис · одит
записва резултата
Бизнес договорът зависи от процеса. Той може да използва същия източник и целева система като друг клиент и все пак да изисква различен отговор.
Разгледайте връзка между магазин и система за имейли. Платформата може да осигури приемане на събития, премахване на дубликати и одитна следа. Собственикът на процеса трябва да определи дали „абониран“ означава разрешение за конкретна маркетингова цел, дали покупка спира напомняне за количка и как промяна на съгласието влияе на вече чакащи съобщения. Това не са функции на конектора, които могат да се отгатнат от имената на полетата.
Илюстрираното съпоставяне в Tajo по-долу копира директно три полета. Забележете липсващото решение: нито един ред не определя разрешение за маркетинг. Повторната употреба на преноса спестява работа, но собственикът на процеса все пак трябва да уточни кой статус позволява кое действие. Подредената карта на полетата показва тази празнина, без да я запълва.
Прегледайте синхронизацията преди изпълнение
Синхронизирайте промените по клиентите с моята имейл платформа.
Синхронизация на клиенти
| Поле източник | Поле цел | Правило |
|---|---|---|
email | EMAIL | Директно |
first_name | FIRSTNAME | Директно |
last_name | LASTNAME | Директно |
Синтетичната предварителна проверка премина успешно
Съпоставени са 3 полета · Няма запис в целевата система
Илюстративен изглед, основан на инструментите на Tajo за съпоставяне. Синтетичната проверка и запазената чернова не активират синхронизация.
| Общ слой | Местен слой |
|---|---|
| Удостоверяване и обновяване на токени | Кой участник има достъп до този процес |
| Транспорт на събития и повторни опити | Кое събитие се брои за бизнес преход |
| Стабилни идентификатори и премахване на дубликати | Кои записи сочат един и същ действителен клиент |
| Дневници и механизми за възстановяване | Кой и как решава спорно състояние |
| Валидация на договора | Какво означават стойностите и кога могат да водят до действие |
Таблицата е граница при проектиране, не твърдение, че всички реализации могат да се разделят толкова чисто.
Повторната употреба се чупи, когато скрива разногласия
Обща платформа често добавя поле за настройка за всяко изключение. Първоначално това изглежда като запазване на повторната употреба. По-късно никой не може да каже дали настройката е техническа опция, правно ограничение или бизнес решение. Общото ядро става дистанционно управление за избори, които не притежава.
Търсете стабилно неизменно условие. „Не прилагай същото изходно събитие два пъти към същия запис в целевата система“ може да живее в общ двигател. „Изпрати отстъпка, когато клиент стане активен“ не може да се споделя, докато „активен“, разрешената аудитория и политиката на офертата нямат отговорници. Двигателят може да изпълнява одобрена политика, но не трябва да я измисля.
Това помага и при поддръжката. Ако API се промени, екипът на платформата може да обнови адаптера и тестовете му. Ако се промени определението за подходящ клиент, собственикът на бизнеса може да обнови политиката и тестовите примери без пренаписване на транспорта. Ясната граница води всяка промяна до човека с правомощие върху нея.
Използвайте повторно механизма, без да изравнявате смисъла
Някои местни правила добавят разход. Платформа без повторно използваем договор става купчина индивидуални скриптове. Отговорът е да намерите повтарящите се механизми, преди да абстрахирате повтарящите се смисли. Добре проектиран общ механизъм може да приема типизирано условие, време на събитие и ограничение на действие, като оставя бизнес определението на условието местно.
Границата трябва да се тества с реални случаи. Вземете нормално събитие, дубликат, закъсняла поправка и отнето разрешение. Попитайте кой слой отговаря за всяка реакция. Ако провал не може да се припише, абстракцията крие отговорност. Ако нов клиент кара общия списък от стойности „активен“ да придобива няколко несвързани тълкувания, общият тип е твърде широк.
Допълващата статия за внедряването разглежда дали способност работи в реален процес. Тази пита какво може да се построи веднъж, без да се изтрие смисълът на процеса.
Интерфейсът между слоевете трябва да е достатъчно изричен, за да отхвърля лошо допускане. Общ двигател може да изисква ID на събитие, време на източника, участник и заявена цел, преди да приеме заявка за действие. Местният процес може да дава политиката, която решава дали действието е позволено. Ако целта липсва, двигателят трябва да откаже заявката; ако политиката е неясна, местният собственик трябва да я изясни. Това е практичен начин да запазите повторната употреба, без да предавате бизнес правомощие на общ код. Документирайте договора с един приет и един отхвърлен пример, после тествайте и двата при промяна на който и да е слой.
Повторно използваемият конектор трябва да прави местния смисъл по-лесен за изразяване и по-безопасен за изпълнение. Никога не трябва да прави две различни обещания да изглеждат еднакви само защото полетата им имат едно име.
Често Задавани Въпроси
Какво обикновено трябва да използва повторно платформата за интеграции?
Стабилни механизми като удостоверяване, транспорт, идемпотентност, повторни опити, дневници и проверки на договори често може да са общи, когато основните изисквания съвпадат.
Какво трябва да остане специфично за бизнеса?
Смисълът на полетата, авторитетът на източника, правилата за съгласие, изискванията за време и правото на действие според статус трябва да се установят за конкретния бизнес и процес.
Как екипите могат да тестват границата?
Опитайте да изразите нов процес с наличните механизми. Ако това променя бизнес смисъла или скрива изключения в обща настройка, дръжте логиката местна и направете интерфейса изричен.