так что если у тебя логика чувствительна к порядку возникновения доменных ивентов - то сингелтон может быть разумным вариантом.

если не чувствительна - у тебя больше вариантов

но зашквара я как не видел так и не вижу

(ивент рекооордер)

если асинхронная, толку от синглтона чуть меньше 0)

(ивент рекооордер)

я это ивент стором называю

тут да, пофиг как называть

если асинхронная, толку от синглтона чуть меньше 0)

ммм... в пределах одного актора профит всеравно есть, а асинхронщина начнется уже по окончанию логической транзакции

у тебя могут несколько логических транзакций паралельно идти но тут уже сагами надо обмазываться, это совсем другая история

да нету никакого профита, если честно) у тебя в сущности всё равно события по очереди идут) как зарайзил, так и отправишь)

либо засейвишь

то есть все упирается в то как у тебя сущности организованы, дробишь ты на конексты или нет, и что тебе нужно от доменных ивентов. Если email-ы отправлять - то вообще плевать как делать

да нету никакого профита, если честно) у тебя в сущности всё равно события по очереди идут) как зарайзил, так и отправишь)

вопрос в том есть у тебя один единый стор на транзакцию или много маленьких (у каждой сущности свои). Да, по хорошему у тебя есть корень агрегата который ивенты хранит только у себя в пределах одной бизнес транзакции...

и по сути только он их должен генерить, но... жизнь не всегда так сладка)

вопрос в том есть у тебя один единый стор на транзакцию или много маленьких (у каждой сущности свои). Да, по хорошему у тебя есть корень агрегата который ивенты хранит только у себя в пределах одной бизнес транзакции...

event_stream (aggregate id) -> one-to-many -> events

event_stream (aggregate id) -> one-to-many -> events

да да, а что делать если у тебя в пределах одной бизнес транзакции несколько логических в разных контекстах, причем все не настолько плохо что надо сагами обмазываться. и вот у тебя уже будет больше одного агрегата задействовано

у меня каждое событие в разном контексте. и если что-то пошло не так, то на совести программиста что с этим делать. Так как уж обмазались сагами, пускай сагами и исправляют

у меня каждое событие в разном контексте. и если что-то пошло не так, то на совести программиста что с этим делать. Так как уж обмазались сагами, пускай сагами и исправляют

ну это ты обмазывался, а сферический разработчик еще не обмазывался)

исправим)

всех по колено в саги посадим)

обработчики доменных событий - это что? не является ли это тоже инфраструктурой?

Ну вот давай пример с юзером. Сверху вниз. Прилетает POST-запрос на /api/v1/users Запрос суть DTO. Далее эта DTO через автомаппер преобразуется в команду "Создать юзера". Эта команда улетает в диспетчер команд. Диспетчер, внутри себя, через какую-нить фабрику (которая скроет работу с IoC контейнером) - срезолвит обработчик (1 команда - 1 обработчик) и вызовет какой-нить метод Handle, в который передаст команду. Обработчику в конструктор приходят: - контекст бд - сервис юзеров Через контекст БД открывается транзакция, через сервис создаётся юзер. По факту создания юзера, из сервиса юзеров возвращается ивент "Создан юзер". В контексте БД сохраняются изменения (но транзакция не коммитится). Если изменения сохранились - то вызывается диспетчер доменных ивентов, куда передаётся ивент "Юзер создан". Далее, диспетчер находит обработчики (1 ивент - много обработчиков) доменного ивента "Юзер создан" и вызывает их. В обработчиках происходит создание инфраструктурных событий, например, формирование имейлов для нотификации. Т.е. ивент "Юзер создан" превращается в команду "Отправить имейл с текстом таким-то туда-то". Сами обработчики эти инфраструктурные команды отправляют в шину. Если все обработчики успешно отработали - происходит коммит транзакции и возврат созданного юзера из команды, который вернётся в ответе на POST-запрос. Параллельно с этим пачка инфраструктурных сервисов разгребает очередь ивентов в рэбите и делает нотификации.

ну это ты обмазывался, а сферический разработчик еще не обмазывался)

т.е. в моей картине мира приложение следит только за консистентностью в рамках 1 агрегата. Согласованность на уровне всех сразу получить в асунковой схеме проблематично. Я как-то красивых вариантов даже не вижу.

Ну вот давай пример с юзером. Сверху вниз. Прилетает POST-запрос на /api/v1/users Запрос суть DTO. Далее эта DTO через автомаппер преобразуется в команду "Создать юзера". Эта команда улетает в диспетчер команд. Диспетчер, внутри себя, через какую-нить фабрику (которая скроет работу с IoC контейнером) - срезолвит обработчик (1 команда - 1 обработчик) и вызовет какой-нить метод Handle, в который передаст команду. Обработчику в конструктор приходят: - контекст бд - сервис юзеров Через контекст БД открывается транзакция, через сервис создаётся юзер. По факту создания юзера, из сервиса юзеров возвращается ивент "Создан юзер". В контексте БД сохраняются изменения (но транзакция не коммитится). Если изменения сохранились - то вызывается диспетчер доменных ивентов, куда передаётся ивент "Юзер создан". Далее, диспетчер находит обработчики (1 ивент - много обработчиков) доменного ивента "Юзер создан" и вызывает их. В обработчиках происходит создание инфраструктурных событий, например, формирование имейлов для нотификации. Т.е. ивент "Юзер создан" превращается в команду "Отправить имейл с текстом таким-то туда-то". Сами обработчики эти инфраструктурные команды отправляют в шину. Если все обработчики успешно отработали - происходит коммит транзакции и возврат созданного юзера из команды, который вернётся в ответе на POST-запрос. Параллельно с этим пачка инфраструктурных сервисов разгребает очередь ивентов в рэбите и делает нотификации.

> из сервиса юзеров возвращается ивент "Создан юзер" прям вот сервис вернет тебе событие? не сущность? > В обработчиках происходит создание инфраструктурных событий зачем так сложно? Просто pub/sub и нужные штуки уже пусть обрабатывают. > Сами обработчики эти инфраструктурные команды отправляют в шину. зачем если они просто могут метод вызвать? или ты думаешь что наличие шины волшебным образом связанность уменьшит? Оно только сделает это неявным. > Если все обработчики успешно отработали - происходит коммит транзакции то есть транзакция не считается успешной если письмо небыло отправлено? а если было отправлено но зависло в баунсед на smtp сервере?

если у тебя выкинулось доменное событие на обработку - это уже факт, то есть все, финито ля транзакция. Все остальное - это уже второстепенные действия которые не влияют на предыдущую.

если тебе надо что бы влияло - добро пожаловать в клуб Maksim любителей саг

если ты хочешь добиться обязательной отправки всех сообщений (в этом примере) - это нужно делать иначе

> из сервиса юзеров возвращается ивент "Создан юзер" прям вот сервис вернет тебе событие? не сущность? > В обработчиках происходит создание инфраструктурных событий зачем так сложно? Просто pub/sub и нужные штуки уже пусть обрабатывают. > Сами обработчики эти инфраструктурные команды отправляют в шину. зачем если они просто могут метод вызвать? или ты думаешь что наличие шины волшебным образом связанность уменьшит? Оно только сделает это неявным. > Если все обработчики успешно отработали - происходит коммит транзакции то есть транзакция не считается успешной если письмо небыло отправлено? а если было отправлено но зависло в баунсед на smtp сервере?

> прям вот сервис вернет тебе событие? не сущность? А почему нет. А внутри события будет содержать созданного юзера. > зачем так сложно? Просто pub/sub и нужные штуки уже пусть обрабатывают. микросервисы > зачем если они просто могут метод вызвать? у другого сервиса? это дорого.

> то есть транзакция не считается успешной если письмо небыло отправлено? а если было отправлено но зависло в баунсед на smtp сервере? нет. меня волнует факт порождения инфраструктурных событий и отправку их в рэбит. А вот если там smtp будет тупить или телега упадёт - меня уже волновать не будет. Это проблемы инфраструктуры.

> прям вот сервис вернет тебе событие? не сущность? А почему нет. А внутри события будет содержать созданного юзера. > зачем так сложно? Просто pub/sub и нужные штуки уже пусть обрабатывают. микросервисы > зачем если они просто могут метод вызвать? у другого сервиса? это дорого.

> А почему нет. потому что это сервис и он мог бы с тем же успехом вернуть юзера или кинуть ивент после сохранения (не доменный а просто)?

> А почему нет. потому что это сервис и он мог бы с тем же успехом вернуть юзера или кинуть ивент после сохранения (не доменный а просто)?

Сервис не умеет сохранять юзеров. Это не его ответственность.

> нет. меня волнует факт порождения инфраструктурных событий и отправку их в рэбит. почему бы в рэббит не кинуть доменный ивент? Что за инфраструктурые события? зачем они?

Сервис не умеет сохранять юзеров. Это не его ответственность.

а нафига он нужен?)

а нафига он нужен?)

Ну, например, при создании юзера нужно пароль похэшировать.

> прям вот сервис вернет тебе событие? не сущность? А почему нет. А внутри события будет содержать созданного юзера. > зачем так сложно? Просто pub/sub и нужные штуки уже пусть обрабатывают. микросервисы > зачем если они просто могут метод вызвать? у другого сервиса? это дорого.

> микросервисы о госпади....

если ты хочешь добиться обязательной отправки всех сообщений (в этом примере) - это нужно делать иначе

всё ж держи попкорн)

Ну, например, при создании юзера нужно пароль похэшировать.

заверни пароль в VO

короч.... тут проблема не с доменными событиями

> микросервисы о госпади....

Ога. 3 чела на яве, 2 на го, 1 на ноде и дотнетчиков 2 + я)

Ога. 3 чела на яве, 2 на го, 1 на ноде и дотнетчиков 2 + я)

не к об этом, я про то что "инфраструктурные события" звучит как ужасная идея

и чё?)

не к об этом, я про то что "инфраструктурные события" звучит как ужасная идея

А как абстрагировать их от знания домена?

Инфраструктурные сервисы.

Я вот такое только придумал.

но связанность то не исчезла - кто-то теперь должен знать о инфраструктуре и к какому сервису это будет относиться?

нету никаких инфраструктурных сервисов, событий и команд

или у тебя 10 сервисов будут знать о сервисе нотификаций?)

короч - микросервисы это про связанность а то что ты описываешь это какой-то трэш

короч... https://www.youtube.com/watch?v=Fuac__g928E

пойду работать а вам вот видяшки

короч - микросервисы это про связанность а то что ты описываешь это какой-то трэш

Почему трэш то?

Почему трэш то?

вот есть у тебя ну не 10, пускай 5 сервисов. Каждый генерит какие-то доменные ивенты на которые надо отправлять email-ы. для имейлов у тебя есть "инфраструктурные события". кто и где будет преобразовывать доменное событие в инфраструктурное?

вот есть у тебя ну не 10, пускай 5 сервисов. Каждый генерит какие-то доменные ивенты на которые надо отправлять email-ы. для имейлов у тебя есть "инфраструктурные события". кто и где будет преобразовывать доменное событие в инфраструктурное?

Обработчики команд доменных.

Обработчики команд доменных.

так...

все в каше

Я же писал в длиннопосте

Появилось событие "Создан юзер". Оно бросается в диспетчер, который хэндлит обрботчики этого события. Эти обработчики создают команды для инфраструктуры и пуляют их в рэбит. Если не пульнулось - не создалось - рэбит лёг - качу транзакцию обратно.

1. получили команду - нашли обработчик 2. обработчик попросил сервис юзеров что-то сделать на что тот вернул результат (то что ты называешь "событием"). Какой-то факт. что он вернет в случае неудачи? Чем это отличается от "вернуть юзера"? 3. обработчик взял этот "доменный ивент" (который оным по факту не является) и сгенерил "инфраструктурные события" - это не события скорее а команды, то есть описание что сделать и данные для этого. так?

типа ProductPurchased -> [SendProductPurchasedNotification]`

по факту "доменный ивент" тут не особо нужен

типа ProductPurchased -> [SendProductPurchasedNotification]`

да и вот это SendProductPurchasedNotification пуляется в рэбит

точно так же как нет разницы между "инфраструктрным" событием и просто RPC вызовом

по факту "доменный ивент" тут не особо нужен

А этих нотификаций может уева гора быть всяких разных.

все сервисы которые генерият "инфраструктурные события" по факту неявно знают о инфраструктуре

точно так же как нет разницы между "инфраструктрным" событием и просто RPC вызовом

Он отложенным получается

связанность системы повышается

добро пожаловать в ад через пол годика

Он отложенным получается

кролик умеет RPC)

кролик умеет RPC)

Я не хочу дожидаться отправки имейла. Я хочу кинуть в кролик команду и работать дальше.

проблема со связанностью - у тебя с таким подходом она выходит дико огромной и в целом во всем этом нет смысла

проблема со связанностью - у тебя с таким подходом она выходит дико огромной и в целом во всем этом нет смысла

Понял тебя.

Я не хочу дожидаться отправки имейла. Я хочу кинуть в кролик команду и работать дальше.

ну то есть ты признаешь что это "инфраструктурные команды" которые по факту просто RPC

Получается инфраструктура должна знать о доменных ивентах?

RPC не означает что ты должен ждать результат

Получается инфраструктура должна знать о доменных ивентах?

какая-то инфраструктура должна, а вот обработчики команд твоих об инфраструктуре знать ничего не должны.

ну то есть ты признаешь что это "инфраструктурные команды" которые по факту просто RPC

RPC - это вызвал и дождался - у меня - запаблишил и забыл

RPC - это вызвал и дождался - у меня - запаблишил и забыл

асинхронный вызов метода, отправка сообщения, как хочешь называй. Это никак не влияет на связанность

короч... посмотри видосик) тебе понравится)

какая-то инфраструктура должна, а вот обработчики команд твоих об инфраструктуре знать ничего не должны.

Ну если я не делаю инфраструктурных команд - то как минимум они умеют ивенты паблишить в кролик

Ну если я не делаю инфраструктурных команд - то как минимум они умеют ивенты паблишить в кролик

потому что у тебя нет доменных событий по факту - у тебя это результат выполнения операции (ты же сам про CQS не так давно говорил)

Тут короче 2 варианта - либо инфраструктура знает про домен, либо домен про инфраструктуру)

инфраструктура знает о тригерах - это норм. Домен знает о инфраструктуре - это не ок

инфраструктура знает о тригерах - это норм. Домен знает о инфраструктуре - это не ок

А являются ли обработчики команд частью домена?

вся проблема в том что твои "доменные события" это не доменные события

вся проблема в том что твои "доменные события" это не доменные события

А Ъ доменные события тогда это как?

А являются ли обработчики команд частью домена?

это что-то типа application level сервисы, уровень оркестрации. Он тоже не должен о инфраструктуре знать

А Ъ доменные события тогда это как?

1. обработчик попросил сервис создать юзера 2. юзер в контроллере запомнил событие что "я жив" 3. кто-то кто знает что транзакция завершилась возьмет у сущност и события и пробросит их в кролик. Это может и хэндлер делать но это не удобно

вся проблема в том что твои "доменные события" это не доменные события

у меня в реализации доменные события - просто графоманство. Они создаются на основании обычных и только в рамках агрегатов. В общем, просто так модно было назвать :) с концептуальной точки зрения я не понял особой разницы, ибо их поведение на миллион процентов одинаковое.

потому янг (или уди, не помню кто из них) и топили за сингелтон EventStore так как в этом случае у тебя при выходе из обработчика команды можно: - закоммитить транзакцию - пробросить все события в кролик

доменное событие может быть выкинуто в кролик ТОЛЬКО когда транзакция завершена и доменное событие становится фактом

у меня в реализации доменные события - просто графоманство. Они создаются на основании обычных и только в рамках агрегатов. В общем, просто так модно было назвать :) с концептуальной точки зрения я не понял особой разницы, ибо их поведение на миллион процентов одинаковое.

что такое "обычные события"?))

ай не, работать

что такое "обычные события"?))

просто события) ни чем не отличающиеся от "не просто событий") о том и речь)

асунковый эвент соурсинг кафно) я не могу придумать как красиво блокировки и согласованность выстроить :( уже месяц возни, а работающей схемы даже на горизонте нету :(

Я тут почитал немного. Сага это грубо говоря - обработчик, начинающийся с определённого доменного события, описывающий бизнес-процесс что ли?

Или неправильно понял?

А это зашкварище.

не, нормально вполне

не, нормально вполне

Ну он тогда будет контейнер дёргать же(