Обычно всё, что отображается, всегда приходит из "источника правды" (source of truth) - это всегда тот bounded context, который владеет данными и всеми бизнесс-правилами, которые оперируют над этими данными. Только так можно избежать неактуальность данных на экране. Поэтому UI в случае с распределёнными системами должен всегда строится исходя из принципов composite UI - все критические данные всегда отображаются UI компонентами которые логически принадлежат к модулям / bounded contexts, где эти данные "живут". Все данные, чьей согласованностью (? consistency) можно либо пренебречь, либо же вообще построить UI таким образом, чтобы эти данные были не нужны, могут быть загружены с кэшированой модели, которую каждый bounded context создает под свои нужды используя сообщения получаемые от других bounded contexts / aggregates через service bus.
Исходя же из требований по минимизации соединений с backend, тут встаёт вопрос оптимизации - наверняка вы рассматривали фасады, которые на стороне сервера могут получить и скомпоновать данные из разных bounded context, тем самым уменьшая количество запросов с клиента.
Подскажите - я правильно понимаю, что в данном случае речь идёт об дирижёре/оркестраторе реализованном как доменный сервис? И что таких оркестраторов у вас не один и не два, и что они друг друга вызывают?
Я не говорил о какой-то определённой реализации концепции бизнес транзакции - меня интересовали детали вашей реализации, чтобы понять насколько эта реализация отличается от уже принятых и часто используемых.
В моём случае мы не усложняем и в большинстве случаев используем хореографию и повышаем наблюдаемость таких процессов для случаев, когда требуется вмешательство.
Наверное я не очень понял, но разве ваш доменный сервис не играет роль того самого дирижёра/оркестратора саги? Разве это не в этом доменном сервисе вы реализуете логику саги?
Моё предположение о зависимости строится на простом наблюдении на протяжении многих лет - как только программистам разрешается открывать соединения к другим сервисам/компонентам/микросервисам - они постепенно начнут это делать, чтобы неминуемо будет приводить к размытию границ bounded contexts, появлению распределенных транзакций (не бизнес, а тех самых плохих, которые замучаешься побеждать), нестабильностям, и многому другому. И, так как вы сказали, что у вас микросервисы общаются друг с другом через gRPC всё вышеприведенное это только вопрос времени. Но опять же, основываю свои предположения на понимании того, что вы тут рассказали.
Что касается альтернатив, то в моём опыте EDA очень сильно решает эту проблему, правда необходимо придерживаться SOA и уже потом поверх всего этого накладывать DDD. Тогда, по опыту, шансы увеличить зависимость компонентов очень снижаются. Окончательно убрать это невозможно в силу человеческого фактора, но тем не менее - ситуация лучше.
Ну общая сложность всего домена проблемы (problem domain) или домена решения (solution domain) в данном случае не должна напрямую отображаться в решении этой задачи. Именно поэтому я и задумался - что же такого даёт вам DDD в этом контексте помимо довольно простой объектной модели и доменного сервиса, который и выполняет роль координатора саги, как я понял из вашего объяснения. Отсюда и моё мнение, что DDD в данном случае - перебор.
Немного забавно читать о том, что вы не согласны с постулатами того, кто, собственно, эту концепцию и сформулировал и описал. Давно я с Грегом не общался - он бы улыбнулся.
Тот факт, что вы используете p2p связь между "микросервисами" (как же я не люблю это идиотское название!) заставляет меня задуматься о высокой зависимости компонентов, которые вынуждены знать друг о друге, которые вынуждены реагировать на нагрузку исходящую напрямую от клиентов, а не исходя из собственных принципов и требований о том, как эти компоненты хотят обрабатывать нагрузку. Да много о чем еще заставляет задуматься.
Привет. Так как тема интересная для меня, позволю себе несколько комментариев и вопросов.
«Ой да сагу добавим, и все заработает». В действительности это не так.
Да нет, в действительности это именно так и есть. Описанное здесь, это ни что иное, как сага, потому как Сага это именно воплощение распределённой во времени бизнес транзакции. Сага неминуема в высоко распределённых системах, если нужно выполнить действия в разных компонентах связанные друг с другом для достижения общего и конечного результата. Непонятно почему автор продолжает рассказывать о "распределённой транзакции" и почему отбрыкивается от концепции Саги. Хотелось бы узнать.
CQRS
Не очень понятно, почему вы делаете такой упор на CQRS в этой статье? В принципе этот аспект совершенно не интересен в этом процессе. Для чего существует CQRS? Только для того, чтобы упростить канал чтения и снизить нагрузку на систему - нет никакого смысла загружать полную модель (под)системы с кучей сложных бизнес объектов только для того, чтобы отобразить что-то на экране или ответить на какой-то заранее известный запрос. Концепция CQRS создавалась Грегом Янгом именно исходя из этих требований. Наложения SOA там не было никогда (это к вопросу о командах).
DDD
Очень заинтересовало упоминание DDD в данном контексте. Вообще DDD хорошо накладывается на реальность там, где есть очень сложный набор бизнес требований, очень высокая сложность моделирования и очень частое изменение этих бизнес аспектов. Конечно из описанного выше сложно ответить однозначно, но сложной модели и взаимосвязи между компонентами тут совсем не наблюдается. Мне показалось, что DDD тут больше для "красного словца" - моделировать кластер, группы машин и машины как-то совсем не сложно для задачи из развертывания и отслеживания результата развёртывания. Хотелось бы понять, что же такого дало DDD в данном случае, потому как DDD подразумевает очень серьезный набор непростых концепций - entites, value objects, bounded contexts, aggregates, repostitories, etc., etc. Опять же агрегаты DDD - это напрямую о transactional boundaries consistency, что в случае с данной областью задач вызывает вопросы. Мне кажется, если и надо было концентрироваться на чём-то в этой статье, то именно на этой области.
Если я понял правильно, то создаётся объектная модель будущего кластера (с узлами и прочим) и после этого выполняются команды по развертыванию каждого объекта в кластере. Модель подгружается как результат обработки сообщения на шине и обновляется для каждого шага и объекта? Если это так, то это именно то, что обычно делается в Саге и объекте состояния Саги - объекте, который и описывает состояние бизнес процесса во времени.
Доменная логика «не вытекает» из домена, а доменные транзакции независимы
Ну, вообще-то, в этом вся концепция домена и агрегата в DDD - оттуда ничего и никогда не "вытекает", потому как это чистейшая абстракция бизнес требований и процессов. Модель создаётся из сохранённого состояния и исполняется для того, чтобы получить новое состояние модели, которое потом и сохраняется с использованием репозитории.
Термин "домен"
Вы очень смело и часто используете этот термин. Где-то даже приравниваете его к микросервису. Это в корне неверно! Домен это большая область проблемы или её решения. Если уже речь о DDD, то говорить надо об агрегатах. Зачастую микросервсисы либо содержат один агрегат, либо же больше - чтобы зазря не расходывать compute resources и объединять код, который подчиняется одним критериям масштабируемости, либо же versioning, либо же release cadence.
От меня
То, что вы выполняете запросы через p2p протокол между вашими подами - это не есть хорошо. Это означает, что у вас (с большой долей вероятности) неправильно проведены границы между агрегатами и bounded contexts, что у вас высокий уровень зависимости компонентов (temporal and spatial). Вам надо глубже погрузиться в SOA, EDA и уже потом накладывать DDD и иногда добавлять CQRS (но только иногда и в основном для UI), чтобы избавиться от p2p взаимодействия.
Заключение
Хочу добавить, что статья так и не даёт толкового объяснения вашей реализации - разговор о том, что это "транзакция в транзакции, поэтому их все видно и это круто" вызывает больше вопросов, чем ответов. Было бы интересно увидеть, что же именно скрывается за этим "транзакции в транзакциях", потому как с их помощью вы опровергаете саги, привносите DDD и говорите о преимуществах. Всё же речь здесь не о транзакциях, а о бизнес процессе создания любого ресурса, результат которого становится известен вызывающему (ну или любому интересующемуся, так как вы используете шину Kafka). И поэтому наблюдаемость любого такого процесса, в принципе, тривиальная задача решаемая через статус каждого компонента и какого-то UI, умеющего эти статусы показывать.
Обычно всё, что отображается, всегда приходит из "источника правды" (source of truth) - это всегда тот bounded context, который владеет данными и всеми бизнесс-правилами, которые оперируют над этими данными. Только так можно избежать неактуальность данных на экране. Поэтому UI в случае с распределёнными системами должен всегда строится исходя из принципов composite UI - все критические данные всегда отображаются UI компонентами которые логически принадлежат к модулям / bounded contexts, где эти данные "живут". Все данные, чьей согласованностью (? consistency) можно либо пренебречь, либо же вообще построить UI таким образом, чтобы эти данные были не нужны, могут быть загружены с кэшированой модели, которую каждый bounded context создает под свои нужды используя сообщения получаемые от других bounded contexts / aggregates через service bus.
Исходя же из требований по минимизации соединений с backend, тут встаёт вопрос оптимизации - наверняка вы рассматривали фасады, которые на стороне сервера могут получить и скомпоновать данные из разных bounded context, тем самым уменьшая количество запросов с клиента.
Подскажите - я правильно понимаю, что в данном случае речь идёт об дирижёре/оркестраторе реализованном как доменный сервис? И что таких оркестраторов у вас не один и не два, и что они друг друга вызывают?
Я не говорил о какой-то определённой реализации концепции бизнес транзакции - меня интересовали детали вашей реализации, чтобы понять насколько эта реализация отличается от уже принятых и часто используемых.
В моём случае мы не усложняем и в большинстве случаев используем хореографию и повышаем наблюдаемость таких процессов для случаев, когда требуется вмешательство.
Наверное я не очень понял, но разве ваш доменный сервис не играет роль того самого дирижёра/оркестратора саги? Разве это не в этом доменном сервисе вы реализуете логику саги?
Моё предположение о зависимости строится на простом наблюдении на протяжении многих лет - как только программистам разрешается открывать соединения к другим сервисам/компонентам/микросервисам - они постепенно начнут это делать, чтобы неминуемо будет приводить к размытию границ bounded contexts, появлению распределенных транзакций (не бизнес, а тех самых плохих, которые замучаешься побеждать), нестабильностям, и многому другому. И, так как вы сказали, что у вас микросервисы общаются друг с другом через gRPC всё вышеприведенное это только вопрос времени. Но опять же, основываю свои предположения на понимании того, что вы тут рассказали.
Что касается альтернатив, то в моём опыте EDA очень сильно решает эту проблему, правда необходимо придерживаться SOA и уже потом поверх всего этого накладывать DDD. Тогда, по опыту, шансы увеличить зависимость компонентов очень снижаются. Окончательно убрать это невозможно в силу человеческого фактора, но тем не менее - ситуация лучше.
Ну общая сложность всего домена проблемы (problem domain) или домена решения (solution domain) в данном случае не должна напрямую отображаться в решении этой задачи. Именно поэтому я и задумался - что же такого даёт вам DDD в этом контексте помимо довольно простой объектной модели и доменного сервиса, который и выполняет роль координатора саги, как я понял из вашего объяснения. Отсюда и моё мнение, что DDD в данном случае - перебор.
Немного забавно читать о том, что вы не согласны с постулатами того, кто, собственно, эту концепцию и сформулировал и описал. Давно я с Грегом не общался - он бы улыбнулся.
Тот факт, что вы используете p2p связь между "микросервисами" (как же я не люблю это идиотское название!) заставляет меня задуматься о высокой зависимости компонентов, которые вынуждены знать друг о друге, которые вынуждены реагировать на нагрузку исходящую напрямую от клиентов, а не исходя из собственных принципов и требований о том, как эти компоненты хотят обрабатывать нагрузку. Да много о чем еще заставляет задуматься.
Привет. Так как тема интересная для меня, позволю себе несколько комментариев и вопросов.
Да нет, в действительности это именно так и есть. Описанное здесь, это ни что иное, как сага, потому как Сага это именно воплощение распределённой во времени бизнес транзакции. Сага неминуема в высоко распределённых системах, если нужно выполнить действия в разных компонентах связанные друг с другом для достижения общего и конечного результата. Непонятно почему автор продолжает рассказывать о "распределённой транзакции" и почему отбрыкивается от концепции Саги. Хотелось бы узнать.
Не очень понятно, почему вы делаете такой упор на CQRS в этой статье? В принципе этот аспект совершенно не интересен в этом процессе. Для чего существует CQRS? Только для того, чтобы упростить канал чтения и снизить нагрузку на систему - нет никакого смысла загружать полную модель (под)системы с кучей сложных бизнес объектов только для того, чтобы отобразить что-то на экране или ответить на какой-то заранее известный запрос. Концепция CQRS создавалась Грегом Янгом именно исходя из этих требований. Наложения SOA там не было никогда (это к вопросу о командах).
Очень заинтересовало упоминание DDD в данном контексте. Вообще DDD хорошо накладывается на реальность там, где есть очень сложный набор бизнес требований, очень высокая сложность моделирования и очень частое изменение этих бизнес аспектов. Конечно из описанного выше сложно ответить однозначно, но сложной модели и взаимосвязи между компонентами тут совсем не наблюдается. Мне показалось, что DDD тут больше для "красного словца" - моделировать кластер, группы машин и машины как-то совсем не сложно для задачи из развертывания и отслеживания результата развёртывания. Хотелось бы понять, что же такого дало DDD в данном случае, потому как DDD подразумевает очень серьезный набор непростых концепций - entites, value objects, bounded contexts, aggregates, repostitories, etc., etc. Опять же агрегаты DDD - это напрямую о transactional boundaries consistency, что в случае с данной областью задач вызывает вопросы. Мне кажется, если и надо было концентрироваться на чём-то в этой статье, то именно на этой области.
Если я понял правильно, то создаётся объектная модель будущего кластера (с узлами и прочим) и после этого выполняются команды по развертыванию каждого объекта в кластере. Модель подгружается как результат обработки сообщения на шине и обновляется для каждого шага и объекта? Если это так, то это именно то, что обычно делается в Саге и объекте состояния Саги - объекте, который и описывает состояние бизнес процесса во времени.
Ну, вообще-то, в этом вся концепция домена и агрегата в DDD - оттуда ничего и никогда не "вытекает", потому как это чистейшая абстракция бизнес требований и процессов. Модель создаётся из сохранённого состояния и исполняется для того, чтобы получить новое состояние модели, которое потом и сохраняется с использованием репозитории.
Вы очень смело и часто используете этот термин. Где-то даже приравниваете его к микросервису. Это в корне неверно! Домен это большая область проблемы или её решения. Если уже речь о DDD, то говорить надо об агрегатах. Зачастую микросервсисы либо содержат один агрегат, либо же больше - чтобы зазря не расходывать compute resources и объединять код, который подчиняется одним критериям масштабируемости, либо же versioning, либо же release cadence.
То, что вы выполняете запросы через p2p протокол между вашими подами - это не есть хорошо. Это означает, что у вас (с большой долей вероятности) неправильно проведены границы между агрегатами и bounded contexts, что у вас высокий уровень зависимости компонентов (temporal and spatial). Вам надо глубже погрузиться в SOA, EDA и уже потом накладывать DDD и иногда добавлять CQRS (но только иногда и в основном для UI), чтобы избавиться от p2p взаимодействия.
Хочу добавить, что статья так и не даёт толкового объяснения вашей реализации - разговор о том, что это "транзакция в транзакции, поэтому их все видно и это круто" вызывает больше вопросов, чем ответов. Было бы интересно увидеть, что же именно скрывается за этим "транзакции в транзакциях", потому как с их помощью вы опровергаете саги, привносите DDD и говорите о преимуществах. Всё же речь здесь не о транзакциях, а о бизнес процессе создания любого ресурса, результат которого становится известен вызывающему (ну или любому интересующемуся, так как вы используете шину Kafka). И поэтому наблюдаемость любого такого процесса, в принципе, тривиальная задача решаемая через статус каждого компонента и какого-то UI, умеющего эти статусы показывать.