Владимир Синявский Инженер следующего изменения Каждое решение меняет цену следующего.

Протокол 003

Второй провайдер не поместился

Один работающий контракт незаметно стал моделью всего рынка.

Контекст интеграции

Продукт бронирует отели через внешние GDS. Первый провайдер, HotelBook, уже подключен: поиск и бронирование работают, приложение почти один в один повторяет его API.

Команда считает продукт универсальным шлюзом и готовится подключить AkademService. Сначала зафиксируйте, что именно доказал первый контракт. Затем получите данные второго провайдера и выберите архитектурную реакцию.

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

Единственное наблюдение

  1. Наблюдение Код Сущности, структура моделей и сценарии взаимодействия повторяют HotelBook 1:1.

Вывод команды

Получившееся приложение называют универсальным шлюзом для нескольких GDS.

Финальный статус после второго контракта: Опровергнуто вторым контрактом

Второй контракт не помещается

AkademService показывает не частный случай, а другой способ устроить интеграцию.

HotelBook

Код

AkademService

Модель

Выбранная исходная позиция появится после первого выбора.

  1. Опровержение Модель Модели данных почти не пересекаются с HotelBook.
  2. Опровержение Процесс Сценарии бронирования устроены по-другому.
  3. Опровержение Деньги Модель взаиморасчетов отличается.

Доказанная причина

Совместимость с HotelBook приняли за знание обо всем классе GDS. Вывод был шире единственного наблюдения, на котором стоял.

В реальной системе пришлось добавлять адаптеры, постепенно выделять абстракции и заводить отдельные таблицы там, где общая модель не ложилась. Итог – 3 GDS, 4 сценария бронирования, 2 типа взаиморасчетов и месяцы работы.

Что именно мы знаем?

Работа с одним провайдером подтверждает совместимость с ним. Статус всей модели пока определяете вы.

  1. Универсально

    Это доменная модель

    Структура выражает общие понятия гостиничного бронирования.

  2. Локально

    Это модель HotelBook

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

  3. Не доказано

    Данных недостаточно

    Один контракт не доказывает ни универсальность, ни уникальность модели.

Что делать после опровержения?

Вернуться к первой версии нельзя. Нужно решить, где теперь проходит честная граница.

  1. Расширять общую модель

    Выделить общий словарь и переводить в него различия провайдеров.

  2. Разделить модели провайдеров

    Сохранить собственные модели и сценарии, связав их на границе бизнес-процесса.

Ниже показаны все 6 маршрутов. При включенном JavaScript останется только выбранный результат.

6 маршрутов, 6 разных цен

Универсальность через исключения

Исходная позиция
Первая интеграция считалась доказательством общей модели.
Новые данные
AkademService показал три класса различий вместо отдельных несовпадающих полей.
Что защищает решение
Повторно использует написанное ядро и ускоряет подключение второго провайдера.
Цена сейчас
Исключения провайдеров начинают проникать в общий словарь.
Следующее дорогое изменение
Третий провайдер или новый тип взаиморасчетов увеличит число условных веток.

Поздняя граница

Исходная позиция
Общая модель считалась доменной, пока второй контракт не опроверг это.
Новые данные
Различия затронули данные, процесс и деньги одновременно.
Что защищает решение
После опровержения создает честную границу интеграции.
Цена сейчас
Границу приходится извлекать из уже связанного кода.
Следующее дорогое изменение
Следующий провайдер дешевле, но текущая переработка максимальна.

Общее после перевода

Исходная позиция
Первый контракт с самого начала оставался диалектом HotelBook.
Новые данные
AkademService дает второй источник, на котором можно искать реальные пересечения.
Что защищает решение
Первый контракт остается на краю системы, а общее появляется только после перевода.
Цена сейчас
Нужно доказать, какие понятия действительно общие, а не просто похожи.
Следующее дорогое изменение
Новый сценарий бронирования проверит устойчивость найденного общего словаря.

Честные различия

Исходная позиция
Модель HotelBook не выдавалась за доменную.
Новые данные
Второй провайдер подтвердил, что различия проходят через несколько слоев.
Что защищает решение
Не маскирует разные контракты и сценарии общей схемой.
Цена сейчас
Возникают дублирование, координация процессов и больше интеграционного кода.
Следующее дорогое изменение
Сквозные продуктовые изменения придется проводить через несколько моделей.

Общее после сравнения

Исходная позиция
Один работающий контракт не считался достаточным доказательством.
Новые данные
AkademService превращает предположение в сравнимые данные.
Что защищает решение
Каноническая модель строится уже на двух источниках.
Цена сейчас
Вторая интеграция идет медленнее из-за явного исследования понятий.
Следующее дорогое изменение
Третий провайдер покажет, не было ли двух источников все еще недостаточно.

Обратимость раньше унификации

Исходная позиция
Команда не обобщала рынок по одному контракту.
Новые данные
Второй провайдер пока показывает больше различий, чем устойчивых пересечений.
Что защищает решение
Сохраняет максимальную обратимость до появления повторяющихся закономерностей.
Цена сейчас
Команда дольше живет с несколькими моделями и операционной сложностью.
Следующее дорогое изменение
Унификация станет отдельным дорогим решением, если сходство подтвердится.