Таблица показывает структуру хранения. Но не всегда показывает: какой бизнес-смысл имеет запись; какое приложение имеет право её менять; какие ограничения применяются в коде; какой порядок событий считается корректным; какие поля являются внутренней реализацией. Поэтому AMPE рассматривает интеграцию баз данных не как «подключиться и читать SQL», а как работу с границей между данными и прикладной логикой.
Начать диагностикуПоэтому возможность сделать UPDATE не означает, что это допустимый интеграционный контракт.
аналитики; выгрузки; миграции; сверки; CDC; технического мониторинга.
валидацию; транзакционную логику; аудит; внутренние события; пересчёты; ограничения приложения.
Это принципиальная разница.
Если база принадлежит нашему собственному сервису, можно проектировать интеграционный read model или controlled write interface.
Если это внутреннее хранилище ERP, CRM или стороннего продукта, схема может меняться без обязательств перед внешними consumers.
AMPE старается не превращать внутреннюю таблицу чужой системы в публичный API.
Когда система не предоставляет другого интерфейса.
Когда требуется read-only доступ к большим объёмам.
Когда нужно построить аналитический поток.
Когда проводится миграция.
Когда нужно организовать CDC.
Когда internal application и integration layer находятся под единым архитектурным контролем.
Но даже тогда мы отдельно фиксируем контракт и ответственность.
Change Data Capture полезен, когда изменения нужно получать быстрее полного периодического чтения.
Но он передаёт технический факт изменения данных.
Это не всегда равно бизнес-событию.
Строка обновилась.
Почему?
AMPE определяет, где CDC достаточно, а где нужен слой, переводящий техническое изменение в бизнес-смысл.
Изменился клиент.
Пересчитался служебный timestamp.
Сработал background job.
Если данные меняются редко.
Задержка в несколько минут допустима.
Объём небольшой.
API отсутствует.
Простой incremental polling по watermark может быть надёжнее сложной streaming-инфраструктуры.
Мы не усложняем интеграцию только ради низкой latency, которая ничего не меняет в бизнес-процессе.
Read replica полезна для разгрузки primary.
Но replication lag может быть значимым.
Если аналитический отчёт отстаёт на секунды — это может быть нормально.
Если система проверяет только что созданный резерв — уже нет.
Поэтому источник чтения выбирается с учётом требований к freshness и consistency.
Колонку переименуют.
Таблицу разделят.
Тип изменят.
Внутреннюю модель нормализуют или денормализуют.
Если integration consumer читает всё напрямую, любое такое изменение становится внешним breaking change.
там, где нужно стабилизировать границу.
views; staging; data contracts; версии; антикоррупционный слой; ETL/ELT transformation —
Сложная аналитика может конкурировать с транзакционной нагрузкой.
Большой cross-system join может сделать интеграцию зависимой сразу от нескольких production-схем.
Иногда правильнее доставить данные в DWH, integration database или другую подготовленную модель и связывать их уже там.
Если mapping живёт только в коде или Excel, интеграция рано или поздно начнёт создавать дубли или неверные связи.
AMPE проектирует identity mapping как отдельную часть модели данных.
внутренний integer ID; UUID; номер контрагента; external ID; код в другой системе.
Постоянный обмен должен уметь работать ежедневно, переживать ошибки и изменения.
Попытка оставить миграционный скрипт в роли вечной интеграции почти всегда создаёт долг.
начало; правила очистки; переезд; контроль полноты; момент переключения.
Источник предоставляет данные через допустимую границу.
Интеграционный слой фиксирует контракт.
Изменения доставляются выбранным механизмом.
Transformation переводит техническую структуру в нужную модель.
Quality checks проверяют критические условия.
Consumers получают данные с понятной freshness и lineage.
Так доступ к БД превращается в управляемую интеграцию.
Production-системы меньше зависят от внешних SQL-запросов.
Изменение схемы не обязательно ломает всех consumers.
CDC используется там, где он действительно нужен.
Аналитическая нагрузка отделяется от транзакционной.
Ownership и identity становятся понятнее.
Прямая запись остаётся исключением, а не универсальным способом интеграции.
И главное — база данных перестаёт быть «самым удобным API» только потому, что к ней удалось получить пароль.
Первый шаг
Например: «Каждые десять минут скрипт читает таблицу заказов чужой системы и переносит новые строки в нашу». Этого достаточно, чтобы понять, насколько эта связь надёжна, что является контрактом и какой механизм должен прийти ей на смену.