Доменно-ориентированный подход к интеграции

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

Интеграция — сторона процесса развития, связанная с объединением в целое ранее разнородных частей и элементов. Интеграция тесно связана с взаимодействием, но тем не менее следует разделять эти понятия.

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

Далее стоит сделать несколько важных допущений, касающихся этой статьи.

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

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

Под доменом интеграции мы будем понимать объединение в целое продуктов/систем и/или отдельных их частей посредством интеграционных решений, то есть создание интеграционных решений.

Под доменно-ориентированным подходом мы будем понимать подход, ориентированный на потребности (business needs) и цели (business goals) бизнес-доменов (business domains). То есть это некий подход, ориентированный на цели бизнес-доменов, позволяющий им решать свои собственные задачи.

За последние годы разработка кардинально поменялась. Вслед за вызовами бизнеса появились гибкие методологии управления, новые шаблоны проектирования (иначе — архитектурные паттерны), технологии и инфраструктуры. Но наибольшие изменения произошли во «владении». Продукты разрабатывают и эксплуатируют сами продуктовые команды, которые в рамках своего домена «владеют» всем, что нужно для развития продуктов, от разработки до инфраструктуры.

И в то же время интеграция как бы застыла на месте. Регулярно в профессиональных сообществах возникают дискуссии о судьбе интеграции (или ESB, которая часто отождествляется с интеграцией).

Эта статья посвящена доменно-ориентированному подходу к интеграции, как ответу на современные вызовы, его отличиям от некоторых других подходов, а также целесообразности следования такому подходу. В ней будут затронуты вопросы владения, архитектуры, технологий разработки интеграционных решений при доменном владении. Также будет дано сравнение доменно-ориентированного подхода с централизованным подходом на основе ESB, определены рамки его применимости и взаимного пересечения с централизованным подходом.

Желание поговорить о доменно-ориентированном подходе и, как следствие, эта статья, родились в результате наблюдения активности в бизнес-сообществе, которое справедливо задается вопросами: «Нужен ли ESB?», «Жив ли ESB, или мёртв?», «Если не ESB, то что же вместо?», «Что же вообще такое интеграция?». По мере погружения в тему мы постараемся найти ответы на эти вопросы.

Мир интеграции существует давно и он богат на различные паттерны и технологии, что позволяет считать его достаточно обширным доменом. При этом мы будем рассматривать доменно-ориентированный подход в сравнении с централизованным подходом на основе ESB, как наиболее распространенным и обсуждаемым в сообществе. Существуют и другие подходы, концепции и вопросы интеграции, такие как API Management, Data Integration и др., однако они не будут затронуты в этой статье.

Когда же возникла острая потребность в интеграции и с какого момента ESB (Enterprise Service Bus — Сервисная шина предприятия) получили широкое распространение?

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

При этом остро возник вопрос интеграции, так как эти системы изначально не были разработаны для взаимодействия друг с другом, а взаимодействие нуждалось в реализации. Так появился паттерн для построения взаимодействия систем, и вместе с этим паттерном соответствующие продукты, называемые ESB. Долгое время ESB, также как и централизованный подход к интеграции, успешно справлялись со многими бизнес-задачами.

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

Таким образом, ESB является композитным паттерном, содержащим в себе множество паттернов, необходимых для интеграции.

Паттерн ESB реализуется в одноименных продуктах Enterprise Service Bus. Интеграционные решения необходимо разрабатывать, развёртывать и исполнять. Как логичное следствие этих потребностей ESB продукты включают в свой состав следующие основные компоненты:

• Среда исполнения интеграционных решения
  
• Инструменты разработки и инструменты развёртывания интеграционных решений в среде исполнения
  
• Сервисы управления, администрирования, отладки и мониторинга интеграционных решений

Если посмотреть на диаграммы с примерами архитектуры ESB, можно увидеть все эти компоненты.

Централизованный подход к ESB обладает некоторыми недостатками, выходящими за рамки технической плоскости. Отметим следующие ключевые недостатки:

• Низкое качество взаимодействий. Централизованная команда интеграции хорошо «понимает» интеграционный домен, но «не понимает» нюансы бизнес-доменов, а бизнес-домены не заботятся о взаимодействии между собой напрямую, полагаясь на то, что все проблемы взаимодействия в контексте интеграции решит ESB и ее команда.
• Большое время поставки изменений (высокий TTM — Time To Market). Централизованная интеграционная команда является «бутылочным горлышком» для доменных команд, так как ее емкость практически всегда недостаточна.
• Непрозрачное бюджетирование. Бизнес-линии сливаются в «общий котёл» интеграции без видимых результатов для «своего» бизнеса.

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

В основном ESB продукты представляют собой довольно тяжёлые централизованные коробочные продукты (COTS). Они обладают своими характерными недостатками:

• Высокий TTM. Объёмным решениям свойственны длительные релизные циклы.
  
• Недостаточно высокая масштабируемость. Решения в монолитной среде исполнения оказывают взаимное влияние друг на друга, сама по себе среда также является тяжёлой и зачастую избыточной. Для масштабирования требуются большая производительность серверов, так как необходимо масштабировать всю систему целиком, а не отдельные его части. Помимо этого подобные решения часто в принципе не подразумевают горизонтального масштабирования.
  
• Высокая стоимость владения (TCO). Стоимость владения включает в себя лицензии, а также дорогое оборудование с высокими мощностями.
  
• Ограниченная возможность найма. Возникают сложности с подбором персонала для обслуживания подобных систем из-за необходимости наличия знаний и опыта по конкретному продукту.

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

Пока предприятия решали задачи централизации, подход ESB работал достаточно эффективно, однако в определённый момент бизнесу потребовалось нечто большее. В результате развития цифровых технологий произошёл сдвиг парадигм, возникли новые организационные подходы, методологии управления, архитектуры, которые позволили сократить TTM и быстро поставлять ценность. Эти подходы организованы вокруг бизнеса, бизнес-доменов и продуктов. Такие образом и получил свое развитие доменно-ориентированный подход к интеграции.

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

Интеграция таким командам нужна здесь и сейчас: у них нет возможности ждать решения со стороны, т.к. бизнесу необходимо конкурировать и обрабатывать обратную связь. Такие решения развёртываются и эксплуатируются автономно, при этом имеют короткие релизные циклы (низкий TTM) и низкую стоимость владения (TCO).

Существует четыре ключевых аспекта доменно-ориентированного подхода:

• Организационный — доменно-ориентированное (децентрализованное) владение интеграцией
  
• Архитектурный — микросервисная архитектура, интеграция без посредников, удобство взаимодействия
  
• Технологический — демократичный инструментарий (фреймворки интеграции, встраиваемые оркестраторы)
  
• Эксплуатационный — независимое развертывание, практики DevOps.
  

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

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

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

Строительными блоками решений в нём являются сервисы, обладающие следующими характеристиками:

• Слабая связанность
  
• Автономность
  
• Организация вокруг бизнес-доменов
  
• Владение небольшими доменно-ориентированными командами
  
• Независимое развертывание и эксплуатация

Таким образом, микросервисная архитектура предоставляет все необходимое для проектирования гибких автономных интеграционных решений.

Важным архитектурным моментом, на котором хотелось бы заострить внимание, является интеграция без посредников. Когда разработка ведётся с нуля, первым шагом является декомпозиция решения на сервисы, распределение между ними ответственности. В контексте доменно-ориентированного подхода для декомпозиции, как правило, используется предметно-ориентированное проектирование (domain-driven design — DDD). Далее выстраивается взаимодействие между сервисами. При этом отсутствует необходимость в посредниках, сервисы органично и естественно взаимодействуют друг с другом.

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

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

• Поставщики должны заботиться об удобстве контрактов для потребителей, а потребители должны заботиться об адаптации к изменениям в контрактах поставщиков.
• Целесообразно использовать подходы Contract-First и API-First для разработки удобных API.
• Версионирование должно быть удобным и предсказуемым. Для этого можно использовать семантическое управление версиями и поддерживать обратную совместимость как минимум между двумя основными версиями контрактов.
• В случае, если у поставщика много клиентов, можно предоставлять готовые клиентские библиотеки для API.

Демократичный инструментарий позволяет успешно решать интеграционные задачи разработчикам, не обладающим глубокими знаниями в области доменно-ориентированным подхода. Дело в том, что готовые решения для всех мыслимых интеграционных задач можно разложить на комбинации шаблонов интеграции (паттерны). Подробно эти паттерны описаны в книге Грегора Хопа и Вульфа Бобби «Шаблоны интеграции корпоративных приложений» и сведены в каталог Enterprise Integration Patterns.

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

Примерами таких фреймворков для экосистемы Java могут служить Spring Integration и Apache Camel. Apache Camel в данном контексте выглядит предпочтительнее, так как превосходит конкурентов по мощности и успешно интегрируется со Spring. Также стоит отметить, что Apache Camel лежит в основании многих ESB продуктов. И Spring Integration, и Apache Camel имеют свой DSL (Domain-specific language — предметно-ориентированный язык) для реализации довольно сложных интеграционных потоков.

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

Для выполнения оркестрации целесообразно использовать готовые оркестраторы. На данный момент рынок предлагает множество решений, таких как Camunda или Cadence, также интересным примером является оркестратор микросервисов Zeebe, разработанный командой Camunda.

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

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

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

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

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

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

Где же совершенно точно могут и должны присутствовать интеграционные решения? Одним из классических примеров необходимости применения интеграционного решения является создание слоя защиты от разрушения (Anti-Corruption Layer). Этот паттерн позволяет изолировать различные подсистемы, разместив между ними промежуточный слой, демпфирующий изменения и разрушения.

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

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

Рассмотрим один из основных трендов в доменно-ориентированном подходе к интеграции. С развитием и взрослением индустрии архитекторы и разработчики осваивают событийно-ориентированную архитектуру.

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

Рост популярности событийно-ориентированного взаимодействия связан с появлением качественных масштабируемых месседж-брокеров, поддерживающий всю инфраструктуру, необходимую для работы с сообщениями, системой публикации и подписки. (Например, Apache Kafka и другие подобные платформы.)

В целом идея построения глобального транзакционного лога системы выглядит привлекательной, ведь событийно-ориентированные архитектуры предоставляют возможность фиксировать изменения сразу по всем системам и агрегировать их в специальном отдельном слое — Data Lake.

В событийно-ориентированное взаимодействие можно включить и интеграцию с унаследованными решениями (Legacy-системами), если обеспечить публикацию изменений данных прямо из их баз данных с помощью инструмента захвата изменений данных (Change Data Capture — CDC). Инструмент позволяет публиковать изменения, которые вносятся в базу данных, в очереди сообщений. Для накопления сообщений применяется слой Data Lake, о котором говорилось выше.

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

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

Также одновременное применение двух подходов возможно в процессе трансформации компании, при переходе на новый тип архитектуры.

Мы рассмотрели ключевые особенности применения доменно-ориентированного подхода к интеграции. Из сказанного выше можно сделать следующие выводы:

1. Доменно-ориентированный подход не является универсальным решением и заменой другим подходам. Его применение целесообразно при доменном владении совместно с продуктовым подходом.
   
2. При проектировании необходимо заботиться о качестве взаимодействия компонентов решений и, по возможности, избегать посредников (интеграционных решений), то есть «лучшее интеграционное решение — то, которого нет».
   
3. При построении интеграционных решений мы используем уже известные организационные и архитектурные подходы и практики, однако при этом используем специфичные инструменты.