В двух интегрируемых системах хранится один атрибут. Как определить его источник истины?
Источником истины должна быть система, которая обладает бизнес-ответственностью за жизненный цикл атрибута и имеет право принимать окончательное решение о его изменении. Выбор нельзя делать только по тому, где атрибут появился первым или где технически проще реализовать запись.
Для каждого атрибута нужно явно зафиксировать владельца, допустимые операции записи, потребителей, правила распространения изменений и поведение при сбоях. Остальные системы должны рассматривать это значение как копию, кэш или производное представление, а не как независимый источник.
В интеграциях данные часто дублируются: одна система хранит профиль клиента, другая использует его для заказов, расчётов или уведомлений. Дублирование нужно для производительности, автономности и работы при временной недоступности соседней системы, но оно создаёт риск расхождения.
Проблема особенно усиливается при двусторонней синхронизации. Если обе системы могут изменять один атрибут, интеграция должна разрешать конфликты, а простое взаимное копирование превращается в неявную конкуренцию за право изменения данных.
Предположим, в CRM и биллинге хранится статус клиента. Если не определить владельца, оператор CRM может изменить статус, а биллинг почти одновременно отправит обратно своё значение. Итог зависит от порядка доставки сообщений, задержек и повторных попыток, а не от бизнес-правил.
Ошибочное решение приводит к потерянным изменениям, циклической синхронизации, неясной ответственности за исправление данных и невозможности объяснить, почему в разных системах отображаются разные значения. Наличие одинакового поля в двух моделях ещё не означает, что обе системы должны иметь право его изменять.
Сначала нужно определить бизнес-смысл атрибута: кто принимает решение, кто отвечает за его корректность и на каком этапе жизненного цикла он изменяется. Эта система становится системой-владельцем или источником истины.
Затем фиксируются правила интеграции:
Важно различать владение данными и владение процессом. Например, CRM может владеть сегментом клиента, а биллинг — признаком блокировки платежей. Если поле объединяет несколько бизнес-фактов, его следует разделить на независимые атрибуты, иначе выбор одного владельца скроет конфликтующие правила.
В требованиях и технической документации нужно описать владельца каждого значимого атрибута, его допустимые состояния, источник изменений, направление обмена, задержку распространения, правила обработки устаревших сообщений и процедуру исправления расхождений. Для контроля полезно хранить версию или время изменения именно из системы-владельца, но это не заменяет бизнес-правило владения.
Компромисс заключается в том, что единый источник уменьшает число конфликтов, но может стать критичной зависимостью. Кэширование и локальные копии повышают доступность и скорость, однако требуют явного описания допустимой устарелости и механизма повторной синхронизации.
Интернет-магазин и складская система оба хранили доступный остаток товара. Магазин хотел мгновенно показывать остаток, а склад изменял его после резервирования, отгрузки и инвентаризации. Двусторонняя запись казалась удобной, но при параллельных заказах приводила к продаже одного остатка нескольким покупателям.
Рассматривались два варианта. Сделать магазин владельцем было проще для пользовательского интерфейса, но он не видел всех складских операций. Сделать склад владельцем требовало организовать события и принять небольшую задержку отображения, зато только склад обладал полной картиной физических изменений.
Выбрали склад как источник истины. Магазин отправлял на склад команды резервирования, а отображаемый остаток получал из складских событий и помечал как потенциально устаревший. Это устранило конкурирующую запись и позволило отдельно контролировать задержку синхронизации; при сбое обмена заказы переводились в состояние ожидания подтверждения, а не подтверждались по старой копии.
Нет. Одна бизнес-сущность может быть распределена между системами: CRM владеет контактными данными, биллинг — платёжным статусом, а служба доставки — адресом фактического получения. Граница должна задаваться на уровне атрибута или отдельного факта, иначе формальный владелец сущности начнёт изменять данные, за которые он не отвечает.
Нужно заранее выбрать одно из правил: запретить изменение, принять команду локально с последующей отправкой, либо разрешить только операции, не нарушающие бизнес-инварианты. Отложенная запись требует идентификатора операции, статуса обработки, повторных попыток и понятного результата для пользователя; нельзя выдавать локальное предположение за подтверждённое состояние источника.
Сообщение должно содержать версию, последовательный номер или другой признак порядка, достаточный для конкретной модели доставки. Получатель применяет изменение только если оно не старше уже принятого состояния; при пропуске версии он инициирует повторную загрузку или сверку. Одного времени на часах разных систем недостаточно, если важен строгий порядок изменений.