Single source of truth в интеграциях: где хранить главную информацию о клиенте, заказе и статусе

Главную информацию следует хранить в системе, которая отвечает за создание, проверку и исправление конкретного бизнес-факта. CRM не должна автоматически становиться владельцем всех данных клиента, а ERP не обязательно должна определять каждый статус заказа. Разные поля одного клиента или заказа могут принадлежать разным системам, но у каждого поля и измерения статуса должен быть один авторитетный источник.

Таким образом, single source of truth в интеграциях не означает единую базу данных для всей компании. Это означает чёткую ответственность: какой источник вправе изменять конкретный факт, где хранится его актуальная версия и как остальные системы получают контролируемую копию. Такой подход позволяет проектировать потоки данных без догадок и неконтролируемой двусторонней синхронизации.

Что на практике означает single source of truth

Single source of truth, или SSOT, — это правило, согласно которому у определённого бизнес-факта есть один авторитетный источник. Если значения в источниках различаются, правильным считается значение из этого источника, пока оно не будет исправлено в рамках установленного процесса.

Важно различать четыре понятия:

•          Авторитетный источник хранит и подтверждает актуальный бизнес-факт.
•          Копия получает данные для использования в другой системе, но сама их не определяет.
•          Модель чтения объединяет информацию для удобного отображения, поиска или формирования отчётов.
•          Исторический снимок сохраняет факт в том виде, в каком он существовал в момент конкретного события.

Например, CRM может быть главным источником данных о контактном лице клиента, а заказ — хранить снимок адреса доставки, действовавшего на момент покупки. Последующее изменение адреса в CRM не должно переписывать историю уже выполненного заказа.

SSOT также не является синонимом хранилища данных. Хранилище данных может быть авторитетным источником утверждённой управленческой отчётности, но обычно оно не предназначено для оперативного исправления адреса клиента или изменения статуса выполнения.

Почему нельзя автоматически объявить одну систему главной

Распространённая ошибка — выбирать систему по её названию: данные клиентов принадлежат CRM, заказы — платформе электронной коммерции, а деньги — бухгалтерской программе. Такая отправная точка понятна, но одной категории системы недостаточно.

Авторитетный источник определяют по ответственности и процессу:

1. В какой системе факт возникает впервые?
2. Какая роль вправе его подтвердить или изменить?
3. Где проверяются обязательные поля и бизнес-правила?
4. При недоступности какой системы процесс фактически останавливается?
5. Где должна сохраняться возможность объяснить, кто, когда и почему изменил значение?
6. Какая система управляет жизненным циклом конкретного объекта?

Система с наибольшим количеством полей не всегда является главным источником. CRM может содержать номер счёта для удобного просмотра, но это не делает CRM владельцем счёта. Аналогично, клиентский портал может показывать объединённое состояние заказа, хотя его компоненты поступают из систем управления заказами, складом и платежами.

На практике определения владельца объекта может быть недостаточно. При необходимости следует определить и владельца поля. Коммерческие отношения с клиентом может вести CRM, юридические реквизиты — система, в которой они проверяются для подготовки счетов, а настройки маркетинговых коммуникаций — решение, в котором эти настройки получают и администрируют.

Статус — не одно универсальное поле

Больше всего противоречий обычно вызывает поле «статус». У одного заказа одновременно может быть несколько независимых состояний:

•          статус приёма заказа;
•          статус оплаты;
•          статус комплектации или оказания услуги;
•          статус доставки;
•          статус счёта;
•          сводный статус, показываемый клиенту.

Если поместить все эти значения в одно поле со свободным текстом, интеграции будет непонятно, что означает «в обработке» и кто вправе менять это значение. Более безопасная модель — разделить статус на измерения. Платёжная система определяет результат оплаты, система управления складом или работами — ход выполнения, а система перевозчика — события доставки.

Показываемый клиенту статус может быть производной проекцией. Например, интерфейс может показывать «готовим заказ» на основании подтверждённой оплаты и начавшейся комплектации. Такая проекция полезна для коммуникации, но не должна перезаписывать базовые статусы в их источниках.

Для каждого статуса необходимо определить допустимые переходы. Если заказ отменён, интеграция не должна случайно вернуть его в состояние «новый» только потому, что поступило запоздавшее событие. Ограничения базы данных могут помогать защищать локальные правила работы с данными. В документации PostgreSQL описано, как ограничения обеспечивают соответствие данных определённым требованиям. Однако правила, охватывающие несколько внешних систем, необходимо реализовывать также на уровне интеграции и процесса.

Метод определения авторитетного источника

Решение можно принять в проверяемой последовательности, а не просто договориться на архитектурном совещании о «главной системе».

1. Составьте список бизнес-фактов

Не начинайте с названий систем. Перечислите факты, которые использует процесс: идентификатор клиента, название компании, контактное лицо, адрес доставки, позиции заказа, цена на момент соглашения, результат оплаты, этап выполнения и номер доставки.

Для каждого факта укажите, где он возникает, где исправляется, кому необходим и нужно ли хранить его историю. Это выявит поля, которые сейчас редактируются в нескольких местах без установленного правила приоритета.

2. Определите бизнес-владельца раньше технического владельца

Место расположения базы данных — не то же самое, что ответственность. Бизнес-владелец определяет смысл значения, требования к качеству и допустимые изменения. Технический владелец поддерживает систему и интеграцию.

Если ни одна роль не может объяснить, кто подтверждает объединение клиентов, отмену заказа или исправление статуса, новое API-соединение не решит проблему. Сначала необходимо принять решение по процессу.

3. Создайте матрицу владения

Для каждого поля или группы фактов укажите:

Значения в таблице следует адаптировать к конкретной компании. Таблица делает ответственность за каждый факт видимой, но указанное в ней распределение систем не является универсальным.

4. Согласуйте идентификаторы

Название или адрес электронной почты не являются надёжными техническими идентификаторами. Каждому клиенту и заказу нужен стабильный идентификатор, но интеграции часто приходится хранить также соответствия идентификаторов из других систем.

Необходимо определить, что происходит при объединении клиентов, деактивации записи или создании заказа до появления карточки клиента. Сопоставление идентификаторов следует хранить в контролируемом месте. В противном случае исправление данных одного клиента может попасть в запись другого.

5. Опишите пути записи и чтения

Если пользователь меняет информацию на клиентском портале, это ещё не означает, что портал становится её источником. Портал может отправить команду на изменение в авторитетную систему, получить подтверждение и только после этого обновить отображение.

Потребители должны знать, является ли полученное значение подтверждённым, ожидает ли оно обработки или представляет собой лишь кешированную копию. Если источник недоступен, решение следует принимать осознанно: заблокировать критическое изменение, поставить запрос в очередь или разрешить только чтение. Скрытую запись в локальную копию в надежде «исправить позже» трудно контролировать.

6. Определите контракт данных

В контракте данных необходимо описать смысл полей, формат, обязательность, допустимые значения статусов, интерпретацию временных меток, версию и семантику удаления или объединения. Следует также указать, содержит ли событие полное состояние объекта или только изменение.

Без такого соглашения две системы могут технически обмениваться одинаковым полем, но интерпретировать его по-разному. Например, «дата заказа» может означать момент создания, подтверждения или оплаты.

Иллюстративная модель клиента и заказа

Предположим, компания использует CRM, систему управления заказами, решение для управления работами и клиентский портал. Этот пример иллюстрирует распределение ответственности и не является готовым архитектурным шаблоном.

CRM управляет коммерческим профилем потенциального и действующего клиента. Система управления заказами создаёт заказ и сохраняет позиции, цену, валюту и реквизиты, использованные на момент заказа. Система управления работами определяет фактический этап выполнения. Портал объединяет данные для чтения и направляет запросы на изменение соответствующему владельцу.

В такой модели портал не становится «ещё одной истиной». Если клиент просит изменить адрес доставки активного заказа, портал отправляет запрос системе управления заказами. Она проверяет, разрешено ли такое изменение на текущем этапе выполнения. Изменение контактного адреса в CRM само по себе не перезаписывает снимок заказа.

В то же время показываемое клиенту уведомление можно вычислять на основе данных из нескольких источников. Важно сохранить возможность объяснить, из каких базовых фактов оно возникло, а не хранить только неоднозначную сводку.

Как перемещать данные между системами

Запрос на запись следует направлять владельцу данных, а об изменениях другие системы можно информировать посредством событий. Описанный Microsoft шаблон Publisher-Subscriber отделяет издателя от потребителей и позволяет нескольким получателям реагировать на опубликованное событие. Это не отменяет необходимости определять авторитетный источник: издатель события должен иметь право сообщать о конкретном факте.

Локальные взаимосвязанные изменения базы данных желательно завершать в одной транзакции. Документация PostgreSQL о транзакциях определяет их как набор действий, который либо выполняется полностью, либо не выполняется. Однако вызовы API нескольких независимых систем нельзя просто считать одной локальной транзакцией базы данных.

Если процесс выполняется частично, необходимы повторные попытки, промежуточные состояния, а иногда и компенсирующие действия. В описании шаблона Microsoft Compensating Transaction подчёркивается, что в среде с согласованностью в конечном счёте компенсация может быть отдельным бизнес-процессом, а не точной технической отменой действий в обратной последовательности.

Переход от нескольких «истин» к одному источнику

В существующей среде нельзя безопасно внедрить авторитетный источник одним лишь изменением конфигурации. Практический переход включает следующие шаги:

1. Провести инвентаризацию полей, интеграций и мест, где пользователи исправляют данные.
2. Найти конфликтующие значения и определить порядок разрешения конфликтов.
3. Выбрать владельца для каждого факта и документировать исключения.
4. Упорядочить соответствия идентификаторов между системами.
5. Прекратить неконтролируемое двустороннее редактирование.
6. Синхронизировать исходные данные и проверить выборку по бизнес-правилам.
7. Переключить путь записи на выбранный источник.
8. Контролировать ошибки, задержки и ручные исправления до отключения старого пути.

Конфликты не следует автоматически разрешать по самой поздней временной метке. Более поздняя запись может оказаться устаревшим импортом или ошибочным ручным изменением. Приоритет должен определяться владением данными, правилами перехода статусов и, если необходимо, проверкой человеком.

Как проверить, работает ли модель

Результат внедрения SSOT можно оценивать с помощью операционных показателей:

•          количество записей без соответствующего внешнего идентификатора;
•          случаи, когда один и тот же факт имеет разные значения в источниках;
•          задержка синхронизации и очередь неуспешно обработанных событий;
•          количество недопустимых переходов статуса;
•          случаи ручного исправления и повторного ввода данных;
•          изменения, для которых невозможно определить источник или инициатора.

Одного совпадения копий недостаточно. Необходимо проверить, продолжает ли бизнес-процесс предсказуемо работать и при временной недоступности какой-либо системы или интеграции.

Ограничения и риски

Один авторитетный источник может стать точкой зависимости процесса. Поэтому необходимо планировать его доступность, резервный режим работы и восстановление. При этом резервный режим не должен незаметно создавать второй постоянный источник.

Не все данные допустимо всегда перезаписывать текущим значением. Для заказов, договоров и других исторических сделок могут потребоваться снимки. Необходимо отличать актуальный профиль клиента от факта, использованного в конкретной сделке.

Журнал аудита также обычно не является источником оперативного факта. Он помогает объяснить историю изменений, но актуальное значение должна определять доменная система. В свою очередь, данные аналитической платформы могут намеренно поступать с задержкой и не подходить для принятия оперативных решений.

Чем больше копий, тем выше риски управления и доступа. У каждой копии должны быть обоснованный сценарий использования, правила доступа, срок хранения и процесс удаления. SSOT не исправляет низкое качество данных автоматически: ошибочная запись в авторитетном источнике лишь будет последовательнее распространяться дальше.

Контрольный список перед внедрением интеграции

До начала разработки команда должна уметь однозначно ответить:

•          Что является авторитетным источником для каждого поля и статуса?
•          Хранят ли другие системы копию, снимок или производную проекцию?
•          Кто вправе инициировать и кто подтверждает изменение?
•          Как сопоставляются идентификаторы?
•          Что происходит с запоздавшим, повторным или недопустимым изменением?
•          Как работает процесс во время недоступности источника?
•          Как будут выявляться конфликты и измеряться качество синхронизации?

Заключение

Правильное место для главных данных — не обязательно технически наиболее центральная система. Это система, которой доверены бизнес-ответственность за конкретный факт и управление его жизненным циклом. Если у каждого поля и измерения статуса есть один владелец, остальные системы можно строить как контролируемых потребителей, а не как конкурирующие источники истины.