На этой странице
У двух клиентов есть поле «активен». Для одного оно означает покупку за последний год. Для второго действующий договор обслуживания. Общий коннектор может правильно передать оба поля. Общее правило, считающее их одним бизнес-состоянием, может ошибиться для одного клиента. Пример условный, не отчёт о внедрении.
Обсуждение общей платформы и местного внедрения описывает компанию, повторно использующую большую часть инфраструктуры, но выполняющую существенную работу в среде каждого клиента. Проценты относятся только к ней. Общий архитектурный вопрос: где кончается общая механика и начинается местный смысл?
Разделите контракт доставки и бизнес-контракт
Контракт доставки может задавать аутентификацию у источника, чтение изменённых записей, сохранение идентификаторов, безопасные повторы и видимость ошибок. Эти операции можно реализовать однажды и испытывать многократно. Они ценны, потому что любой интеграции нужен надёжный путь данных.
Бизнес-контракт говорит, какая запись достоверна, что означает статус, когда разрешено действие и кто исправляет ошибку.
- Общая передача идентичность · повтор · ID события
доставляет допустимое событие
- Местная политика смысл · согласие · время
решает, разрешено ли действие
- Разрешённое действие запись · аудит
фиксирует итог
Бизнес-контракт зависит от процесса. Он может использовать те же источник и назначение, что и другой клиент, но требовать иного ответа.
При связи магазина с платформой email общая система обеспечивает приём событий, удаление дублей и след аудита. Владелец процесса определяет, означает ли «подписан» согласие на конкретный маркетинг, подавляет ли покупка напоминание о корзине и как изменение согласия влияет на уже поставленные в очередь сообщения. Это не свойства коннектора, выводимые из названий полей.
Показанная ниже схема Tajo напрямую копирует три поля. Обратите внимание на отсутствующее решение: ни одна строка не определяет разрешение на маркетинг. Повторное использование механизма передачи экономит работу, но владелец процесса должен указать, какой статус допускает какое действие. Аккуратная схема показывает пробел, но не закрывает его.
Проверьте синхронизацию до запуска
Синхронизируйте изменения клиентов с моей email-платформой.
Синхронизация клиентов
| Исходное поле | Целевое поле | Правило |
|---|---|---|
email | EMAIL | Напрямую |
first_name | FIRSTNAME | Напрямую |
last_name | LASTNAME | Напрямую |
Синтетическая проверка пройдена
Сопоставлены 3 поля · Записи в целевую систему нет
Иллюстрация основана на инструментах сопоставления Tajo. Синтетический предпросмотр и сохранённый черновик не активируют синхронизацию.
| Общий слой | Местный слой |
|---|---|
| Аутентификация и обновление токена | Кто может обращаться к процессу |
| Передача событий и повторы | Какое событие считается бизнес-переходом |
| Устойчивые идентификаторы и удаление дублей | Какие записи относятся к одному настоящему клиенту |
| Журналы и восстановление | Кто и как разрешает спор о состоянии |
| Проверка контракта | Что означают значения и когда они дают право действовать |
Таблица показывает границу проектирования, а не обещает столь идеальное разделение любого продукта.
Повторное использование ломается, скрывая различия
Общая платформа часто добавляет поле настройки для каждого исключения. Сначала кажется, что так сохраняется повторное использование. Позже никто не отличает технический вариант от юридического ограничения или бизнес-решения. Общий центр становится пультом управления выборами, ему не принадлежащими.
Ищите устойчивый инвариант. «Не применяй одно исходное событие дважды к одной записи назначения» может жить в общем движке. «Отправь скидку, когда клиент станет активным» не может быть общим до определения «активного», допустимой аудитории и политики предложения. Движок исполняет утверждённую политику, а не придумывает её.
Это облегчает поддержку. Если API изменяется, платформенная команда обновляет адаптер и тесты. Если меняется определение подходящего клиента, владелец бизнеса обновляет политику и примеры, не дожидаясь переделки транспорта. Чёткая граница направляет изменение к полномочному человеку.
Повторяйте механику, не сглаживая значения
Местные правила тоже стоят денег. Платформа без общего контракта становится сборником отдельных скриптов. Сначала обобщайте повторяемые механизмы, а не похожие значения. Хороший общий примитив может принимать типизированное условие, время события и предел действия, оставляя бизнес-определение условия местным.
Проверяйте границу на настоящих случаях: обычное событие, дубль, позднее исправление и отзыв разрешения. Спросите, какой слой отвечает за каждый ответ. Не удаётся назначить ответственного, значит абстракция скрывает владение. Если новый клиент заставляет общий тип «активен» получать несколько несвязанных толкований, тип слишком широк.
Соседняя статья о внедрении спрашивает, работает ли способность внутри реального процесса. Здесь вопрос в том, что можно построить один раз, не уничтожив смысл процесса.
Интерфейс между слоями должен отклонять плохое предположение. Общий движок может требовать ID события, исходное время, действующее лицо и заявленную цель до принятия действия. Местный процесс поставляет политику допустимости. Без цели движок отказывает; при неоднозначной политике решает местный владелец. Это сохраняет повторное использование без передачи бизнес-полномочий общему коду. Документируйте контракт одним принятым и одним отклонённым примером и проверяйте оба после изменения любого слоя.
Повторно используемый коннектор должен помогать выразить местный смысл и безопасно исполнить его. Одинаковое имя поля никогда не должно делать два разных обещания одинаковыми.
Часто Задаваемые Вопросы
Что платформе интеграции обычно следует использовать повторно?
Устойчивые механизмы аутентификации, передачи, предотвращения дублей, повторных попыток, журналирования и контрактных проверок часто можно разделять при совпадении требований.
Что остаётся специфичным бизнесу?
Смысл полей, полномочие источника, правила согласия, временные требования и право действовать по статусу определяются для конкретной компании и процесса.
Как проверить эту границу?
Попытайтесь описать новый процесс существующими примитивами. Если это меняет бизнес-смысл или прячет исключения в общей конфигурации, оставьте логику местной и сделайте интерфейс явным.