Шины - ключевой элемент качественной архитектуры | Андрей Путин

Подписаться 7 тыс.

Просмотров 3 тыс.

50% 1

Как за пару минут проанализировать качество IT-архитектуры предприятия. Лакмусовые бумажки сильной и слабой связанности IT-сервисов. В каких случаях шина (middleware = промежуточный слой) может стать инструментом для создания качественной архитектуры, а когда может еще сильнее усугубить сильную связанность.
Спикер:
Андрей Путин, CEO KT.Team
Тайм-коды:
0:00 Закон слабой связанности
0:42 Как слабая связанность связана с интеграциями
1:25 Что такое контекст. Контекст приложения и
контекст предприятия = общий контекст
2:30 Примеры слабой и сильной связанности. Лакмусовые бумажки
3:59 Подключение нового сервиса
5:00 Мониторинг
6:00 Внедрение BI системы
8:00 Паутина плохой архитектуры
10:01 Монолит и инновации
11:52 Почему шины - не серебряная пуля, как использование шин может стать карго культом
15:35 Мифы про шины и ESB
17:28 Как выбрать шину
Полезные ссылки:
Интеграция приложений без ESB | Как ПО становится некрасивым и сложным | Зачем нужен ESB
• Интеграция приложений ...
Сервис-ориентированная архитектура. Цифровая копия бизнеса | kt.team
• Сервис-ориентированная...
Что такое закон Мела Конви
• Что такое закон Мела К...
Статья “Закон Конвея”: habr.com/ru/companies/engelba...
Книга Эрик Эвaнс Предметно-ориентированное Проектирование (DDD):
www.ozon.ru/product/predmetno...
Наш сайт: kt-team.ru/
#esb #middleware #IT-архитектура #шины #ИТ-архитектура #интеграции #Андрей_Путин

Опубликовано:

31 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 5

@artemkhoroshilov6363 Год назад

Лайк в поддержку. Важно. Больше движа по теме, нужно общественное понимание проблемы.

@TBadalov 10 месяцев назад

Ни о чем, простите. Чем вам сам интернет не ESB? Указал имя хоста, пакеты прошли по тем же проводам через днс, нашли получателя, направили по тем же проводам на нужные машины. Пририсовав квадратик перед какой-то системой и заставив всех теперь отправлять запросы в этот квадратик, проблема остается той же - все клиенты должны реализовать API.

@andrey-putin-ktteam 10 месяцев назад

Принцип "синхронизация с контрактом" (общим контекстом), а не с сервисом. У всех сервисов уже есть какой-то API -- даже если это взаимодействие с файлами через FTP. "квадратик" (ETL вы имеете ввиду?) служит для преобразования из контекста приложения в контекст предприятия. Все нюансы потребления, вся сложность забора данных -- в этом ETL слое. Сервис же просто предоставляет свои данные (и это единственное что он должен делать). Тогда у вас может быть любой сервис, который не содержит логики отправки внутри, это может быть и облачный и какой угодно сервис. А входы и выходы видны всей организации в лаконичном виде. Это заставляет ответить на вопрос "а в чем ключевой смысл бизнес-процесса этого сервиса". А дальше этот клубок начинает распутываться. Принцип слабой связанности (он же кстати SOLID + DDD) выделен как ключевое например командой Кима Фосгрина и Хамбла в Accelerate (которая описывает методику DORA), есть в плейбуках Яндекса и далее, и мне очень жаль что мне не удалось донести суть этого принципа.