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