Репост из: Yet Another Analyst
#интеграция
Sync-Async, теория относительности
Начало тут.
Sync-Async - свойство взаимодействия между двумя акторами. Актором может выступать как компонент системы, так и живой человек, особой разницы нет.
Одно и то же взаимодействие может одновременно быть синхронным и асинхронным в зависимости от того, как мы на него смотрим.
Цель процесса
Я пришел на обед, моя цель - запихнуть в себя сколько-то калорий для выживания. Если на столе нет меню, то взаимодействие Гость-Официант, в котором я прошу принести его, будет синхронным, т.к. процесс заблокирован.
Если я пришел в рестик на встречу, чтобы договориться о ценах-сроках проекта, то ожидание меню меня никак не блокирует. То же самое взаимодействие Гость-Официант становится асинхронным.
Общий контекст
Если мне нужно подать заявление на госуслугах, то взаимодействие User - UI будет синхронным: заполнить заявку, отправить, дождаться справку, скачать ее.
Если расширить этот процесс до “получить набор документов для визы”, то после отправки заявки я могу пойти оформлять другие документы. Тогда первое взаимодействие не блокирует весь процесс и становится асинхронным.
Уровень абстракции
Этот вопрос рассматривали в прошлом посте. Добавлю только, что можно смотреть на взаимодействия начиная с бизнес-процессов и пользовательского опыта, спускаясь до низкоуровневых протоколов. На разных уровнях абстракции свойство Sync-Async может меняться.
Например, получение справки может быть синхронным для пользователя и асинхронным с точки зрения взаимодействия сервисов под капотом. Например, через коллбек. При этом схема асинхронного коллбека состоит из 2-3 синхронных взаимодействий.
В итоге синхронность или асинхронность взаимодействия зависит от point of view, и может отличаться у разных наблюдателей. Например у дизайнера, продакта, разраба, архитектора. Полезно помнить об этом.
Sync-Async, теория относительности
Начало тут.
Sync-Async - свойство взаимодействия между двумя акторами. Актором может выступать как компонент системы, так и живой человек, особой разницы нет.
Одно и то же взаимодействие может одновременно быть синхронным и асинхронным в зависимости от того, как мы на него смотрим.
Цель процесса
Я пришел на обед, моя цель - запихнуть в себя сколько-то калорий для выживания. Если на столе нет меню, то взаимодействие Гость-Официант, в котором я прошу принести его, будет синхронным, т.к. процесс заблокирован.
Если я пришел в рестик на встречу, чтобы договориться о ценах-сроках проекта, то ожидание меню меня никак не блокирует. То же самое взаимодействие Гость-Официант становится асинхронным.
Общий контекст
Если мне нужно подать заявление на госуслугах, то взаимодействие User - UI будет синхронным: заполнить заявку, отправить, дождаться справку, скачать ее.
Если расширить этот процесс до “получить набор документов для визы”, то после отправки заявки я могу пойти оформлять другие документы. Тогда первое взаимодействие не блокирует весь процесс и становится асинхронным.
Уровень абстракции
Этот вопрос рассматривали в прошлом посте. Добавлю только, что можно смотреть на взаимодействия начиная с бизнес-процессов и пользовательского опыта, спускаясь до низкоуровневых протоколов. На разных уровнях абстракции свойство Sync-Async может меняться.
Например, получение справки может быть синхронным для пользователя и асинхронным с точки зрения взаимодействия сервисов под капотом. Например, через коллбек. При этом схема асинхронного коллбека состоит из 2-3 синхронных взаимодействий.
В итоге синхронность или асинхронность взаимодействия зависит от point of view, и может отличаться у разных наблюдателей. Например у дизайнера, продакта, разраба, архитектора. Полезно помнить об этом.