Архитектура Enterprise-интеграций: Как подружить внешний B2B-портал и тяжелое ядро (ERP/Tririga) без потери данных

[Rorick]

Как портал узнаёт текущие значения? У него своя база, которая синхронизируется из ESB?

[Evpolov]

Отличный вопрос, вы зрите в корень.

В правильной Enterprise-архитектуре мы используем паттерн CQRS (Command Query Responsibility Segregation).

Да, у B2B-портала есть своя «легкая» база данных (или распределенный кэш). Чтение напрямую из ERP/Tririga на каждом запросе — это путь к деградации производительности и зависимости от аптайма ядра.

Как это работает в нашей связке:

1. Первичный слой (Read Model): Портал хранит локальную копию необходимых данных. Это обеспечивает мгновенный отклик интерфейса (Latency < 100ms) и работу портала, даже если ядро ушло на регламентное обслуживание.

2. Синхронизация (The Pulse): ESB работает как «сердце». При любом изменении в Master-системе (ядре), она инициирует событие и «пушит» обновленные значения в базу портала. Мы получаем Eventual Consistency (согласованность в конечном счете) — задержка обычно составляет доли секунды.

3. Single Source of Truth: Важно понимать, что база портала — это лишь «отражение». Источником правды всегда остается ядро. В паспорте АОК для таких модулей мы всегда жестко прописываем параметр @OWNERSHIP, чтобы разработчик знал: эти данные в базе портала нельзя менять локально, их можно только «просить» изменить через шину.

Именно наличие собственной базы позволяет реализовать механизм Offline First — подрядчик видит свои лимиты, даже если связь с центральным офисом временно нестабильна.