шо. опять..)

Снова)

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

шо. опять..)

надо же послушать, кто какое гуано наворотил и обсудить свое)

Уди Янгом недоволен. Он предлагает доменные ивенты через синглтон паблишить.

Понятно что не доволен. Для них это в первую очередь бизнес и конкуренция.

Понятно что не доволен. Для них это в первую очередь бизнес и конкуренция.

Типа всем советую говно, а сам пишу нормально?)

изи страта)

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

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

Я вот думаю - а не лишнее ли звено этот рекордер?

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

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

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

Сервис локатор не хочу

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

На шарпике пишу бэкэнды если что - доткоры там

Больше проблема если ивенты уйдут в диспатчер (ивент бас, etc.) до персиста сущности

вот вот

Вот этот момент принципиален, ибо можно нехило так выстрелить в ногу себе

Больше проблема если ивенты уйдут в диспатчер (ивент бас, etc.) до персиста сущности

А если мне нужна синхронная обработка команд?

Вернее эвентов

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

у меня она и так синхронная)

Синхронно или нет опять же не важно. Важен порядок: сначала удостоверились что сущность сохранилась, потом диспатчим ивенты

но можно и асинк сделать

Но по своей сути ивенты это асинхронная схема

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

Так что если важен порядок то надо пересматривать схему ивентов

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

Вроде того

А для асинхронной обработки - типа мыло отправить - обработчик будет этот ивент писать в рэбит какой-нить. Рэбит лежит - значит юзеры не создаются, потому что мои сервисы не могут общаться между собой. Ну а из рэбита его какой нить сервис отправки имэйлов заберёт.

У меня пока так: сущность, персист, комит транзакции, диспатчинг ивентов

Порядок чуть другой

У меня пока так: сущность, персист, комит транзакции, диспатчинг ивентов

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

Норм такое решение?

Тут вопрос зачем? Я пока не вижу этому достаточных аргументов

Как по мне не ок, проблему ты сам выше отписал

ивенты это сайд эффект завершенного действия

и в сценарии с юзером лучше делать в нем поле emailSent и проверять его имхо

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

ивенты это сайд эффект завершенного действия

Это не совсем так. Ивенты это source of truth.

Уведомление - это запись в рэбит.

и в сценарии с юзером лучше делать в нем поле emailSent и проверять его имхо

Там этих имейлов трилион может быть.

И смс

и телега

и что угодно вообще

но тем не менее в моем понимании действие не должно зависеть от ивентов

и в сценарии с юзером лучше делать в нем поле emailSent и проверять его имхо

Тогда уже выносить в сагу

Поидее в обработчиках ивентов живёт логика, которая создаёт пачку "сервисных" ивентов. Т.е. из ивента "Создан юзер" создаёт ивенты типа "Отправить e-mail с текстом таким-то на такой-то адрес", или "Отправить в телеграм такой-то вот такое-то сообщение". А вот уже эта сервиснные сообщения уходят в рэбит, и там их забирают сервисы, которые только умеют слать что-то куда-то и понятия не имеют о юзерах и домене вообще. Т.е. занимаются сугубо инфраструктурными вещами.

Не) эвент не указывает что сделать, а говорит что сделано

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

Поидее в обработчиках ивентов живёт логика, которая создаёт пачку "сервисных" ивентов. Т.е. из ивента "Создан юзер" создаёт ивенты типа "Отправить e-mail с текстом таким-то на такой-то адрес", или "Отправить в телеграм такой-то вот такое-то сообщение". А вот уже эта сервиснные сообщения уходят в рэбит, и там их забирают сервисы, которые только умеют слать что-то куда-то и понятия не имеют о юзерах и домене вообще. Т.е. занимаются сугубо инфраструктурными вещами.

это команды)

Не) эвент не указывает что сделать, а говорит что сделано

Тогда я ошибся в терминологии) Утро) Это команда)

Поидее в обработчиках ивентов живёт логика, которая создаёт пачку "сервисных" ивентов. Т.е. из ивента "Создан юзер" создаёт ивенты типа "Отправить e-mail с текстом таким-то на такой-то адрес", или "Отправить в телеграм такой-то вот такое-то сообщение". А вот уже эта сервиснные сообщения уходят в рэбит, и там их забирают сервисы, которые только умеют слать что-то куда-то и понятия не имеют о юзерах и домене вообще. Т.е. занимаются сугубо инфраструктурными вещами.

имхо, не нужное переусложнение

Ну типа в обработчиках порождать инфраструктурные команды.

имхо, не нужное переусложнение

А как лучше?

И проще

Казалось бы, при чём тут саги

Сервисные события от обычных отличаются, внезапно, ни чем

Казалось бы, при чём тут саги

у тебя там попкорн вкусный?)

Да тут Антон отдувается) а я так, набрасываю иногда)

ну я ж потому и говорю, что ты просто с попкорном сидишь)

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

Ну так и есть в идеальном мире. Как ивенты будут обрабатываться (и будут ли) породивший их модуль мало волнует. Он свою часть выполнил и сообщил.

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

Ну поидее цепочка такая: Команда -> Обработчик команды (тут порождаются доменные ивенты) -> Диспетчер доменных событий -> Обрабочики доменных событий -> Инфраструктурные команды -> Шина -> Инфраструктурные сервисы

инфраструктурные команды ничем не отличаются от обычных (в идеале)

инфраструктурные команды ничем не отличаются от обычных (в идеале)

Отличаются.

Объясню

слева команда, справа команда) в чем разница?)

у любителей обмазаться шинами чуток другой флоу. и, да, команды отличаются ни чем

Уди Янгом недоволен. Он предлагает доменные ивенты через синглтон паблишить.

поскольку доменный ивент это состоявшийся факт - не вижу проблемы

я (для ивентов, правда) сделал так у меня диспетчер команд из ивент рекордера выгребает ивенты и уже по их классам (наследуется от Event или AsyncEvent кидает либо в диспечтер (для синхронных) либо в гейтвей (для будущих асинхронных)

Я хочу чтобы инфраструктура ничего не знала кроме того что она должна делать. Т.е. сервис отправки имейлов - принимает на вход: - мыло - тему сообщения - тело сообщения - флаг, указывающий то, является ли тело плейнтекстом, либо хтмлем и всё. он не знает ни про юзеров, ни про то что они создавались или что-то там ещё

шина -> команда -> сервис -> событие -> шина -> обработчики события (сервисы/саги. не важно) -> ....

Пушо чтобы хэндлеры инстанциировать - надо либо сервис-локатор юзать (что зашквар), либо инстанциировать их ручками - что тоже зашквар.

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

Я хочу чтобы инфраструктура ничего не знала кроме того что она должна делать. Т.е. сервис отправки имейлов - принимает на вход: - мыло - тему сообщения - тело сообщения - флаг, указывающий то, является ли тело плейнтекстом, либо хтмлем и всё. он не знает ни про юзеров, ни про то что они создавались или что-то там ещё

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

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

Если что - у меня CQS - не CQRS Ии тем более не ES.

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

Но тогда инфраструктура знает о кишках системы

у меня тоже)

Если что - у меня CQS - не CQRS Ии тем более не ES.

CQS на уровне отдельных методов, и в целом я ни CQRS и ES не имел ввиду. Разговор только о доменных событиях

о юзерах, заказах и прочем дерьме

Но тогда инфраструктура знает о кишках системы

ничего она не знает

CQS на уровне отдельных методов, и в целом я ни CQRS и ES не имел ввиду. Разговор только о доменных событиях

Ну ок) Это я для ясности мысли)

Чтобы мы одну архитектуру имели ввиду

Чтобы мы одну архитектуру имели ввиду

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

о юзерах, заказах и прочем дерьме

то есть юзеры и заказы должны о инфраструктуре знать? у тебя проблемы с инверсией зависимостей

то есть юзеры и заказы должны о инфраструктуре знать? у тебя проблемы с инверсией зависимостей

Не знают. Знают об этом обработчики доменных событий.

Связующее звено между инфраструктурой и доменом

А инфраструктура тупа

Не знают. Знают об этом обработчики доменных событий.

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

пришел ивент ProductPurchased, листенер его словил и попросил другой модуль что-то сделать

Maksim поделись попкорном)

а теперь вернемся к вопросу чем это хранение ивентов в сингелтоне это зашквар?

Maksim поделись попкорном)

да не. тут просто в кучу как-то всё сгребли) думаю, разберутся скоро)

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

вроде как все ж хорошо, где зашквар? ответственность разделена

удобно

не надо делать сложных юнит оф ворков и прочего

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

и с CQS все хорошо)

p.s. я один раз пока только пробовал в сигелтоне хранить ивенты и в этом есть очень много плюсов, правда минусы тоже есть. Чаще я храню события прямо в сущности но мне тут очень не нравится то что у меня интерфейс сущности чуть-чуть загрязняется всякими releaseEvents

зато проще контролировать

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