Немного мудрости
Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia.
Если в "дошинную" эпоху общепринятой концепцией была интеграция различных систем друг с другом напрямую, т.н. соединение "точка-точка", то с появлением шины — она становится главным транспортным узлом в интеграционной архитектуре предприятия, в определённом смысле объединяя в себе все API предприятия:
скачать схему в формате diagrams.net (бывший draw.io)
Общая концепция КСШ:
скачать схему в формате diagrams.net (бывший draw.io)
КСШ собой эволюционный виток архитектурной мысли в рамках сервисно-ориентированной архитектуры в "домикросервисную эпоху". Хорошо подходит для средних размеров предприятий с относительно небольшим количеством ИС (десятки).
Оглянувшись на свой и чужой опыт, можно извлечь несколько уроков использования КСШ:
- Заклинаю, не надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует только как транспорт.
Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки — нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock;
-
ESB могут стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM (time to market).
Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, знающих Шину — стремится к нулю.
- На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли "вешать" разработку и тестирование на вендора?
Автотесты требуют всегда актуальных артефактов п.4;
- Должен быть выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех ИС, работающих с Шиной. Нужны Архитекторы, и они должны быть "пишущие".
В основном это касается крупных ESB, на которые "нацеплены" большая часть ИС предприятия.
Если мы говорим о "небольших" шинах типа Kafka и RabbitMQ, то с ними всё гораздо проще, кроме того, они часто задействованы в
микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.