ивенты?

и может управлять ProductStore( Catalag, ну или любое другое название)

продукты он может менять сам по идее

то есть внутри будет EventDispatcher?

если их кол-во относится к продукту

зависит от реализации

ну мы говорим про “идеальную"

доменные ивенты?

я не знаю, какая идеальная, знаю только хреновые)

доменные ивенты?

угу

получается Order имеет внутри Mailer?

нет

то есть внутри будет EventDispatcher?

нет

доменные евенты? можно поподробней?

ну мы говорим про “идеальную"

order.cancel() events = order.releaseEvents() dispatcher.dispatch(...events);

то есть в процессе своей жизни "order" запоминает что с ней происходило

хм

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

скажем оредр внутри вызвал catalog.incrementProductCount(this)

скажем оредр внутри вызвал catalog.incrementProductCount(this)

нет, ордер не имеет доступа к какталогу

ну то есть создал ивент не усебя

ну то есть создал ивент не усебя

он не может этого сделать

ок

Catalog будет слушать ивент order_canceled?

да, не сам каталог а что-то над ним

некий менеджер процесса который слушает события и тригерит операции

что-то

?

сервис какой-нить, сага, или вообще фронт...)

есть такое понятие сервисный слой

что именно - за кадром) что-то

ну мы в итоге пришли к CatalogManager.onOrderCanceled

ну это не совсем "сервисный слой"

да и ты наверное имел ввиду application layer

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

а чем он от апликейшена отличается?

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

а теперь представь что он не нужен)

ну мы в итоге пришли к CatalogManager.onOrderCanceled

и чем это лучше чем CatalogManager.CancelOrder ?

а чем он от апликейшена отличается?

тем что сервисный слой это не только координация

и чем это лучше чем CatalogManager.CancelOrder ?

тем где бизнес логика

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

ни одного if-а в нем быть не должно

(мы же все еще про идеальное?)

о да

тем где бизнес логика

если ордер закенселили, нужно сделать доступными продукты из ордера для следующего заказа

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

разве не бизнес логика?

разве не бизнес логика?

onOrderCanceled(event: OrderCanceled): void { // достать айдишки продуктов // попросить сущность каталог снять резервацию товаров }

2-3 строчки кода получится

а вся бизнес логика где-то внутри

у меня в целом вся (абсолютно) логика в сервисах лежит. Оно как-то с божьей помощью дёргается событиями/командами и ок

причем "каталог" вполне может быть сервисом

у меня в целом вся (абсолютно) логика в сервисах лежит. Оно как-то с божьей помощью дёргается событиями/командами и ок

ой и ты хочешь сказать что у тебя там сущности анемичные?) геттеры и сеттеры на ES?)

абсолютно все управление процессом может быть?

ой и ты хочешь сказать что у тебя там сущности анемичные?) геттеры и сеттеры на ES?)

нету геттеров и сеттеров) зачем?)

// попросить сущность каталог снять резервацию товаров - это прям и есть бизнес логика

// попросить сущность каталог снять резервацию товаров - это прям и есть бизнес логика

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

но, да, сами сущности вполне себе анемичные. на этих словах где-то в бегах залетает Анетон)

можно даже без ивентов это делать

но, да, сами сущности вполне себе анемичные. на этих словах где-то в бегах залетает Анетон)

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

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

всё, что я делаю - херня)

всё, что я делаю - херня)

я всего лишь допускаю что ты делаешь сложнее чем могло бы быть)

// попросить сущность каталог снять резервацию товаров - это прям и есть бизнес логика

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

я всего лишь допускаю что ты делаешь сложнее чем могло бы быть)

я не в том плане) я сам так отношусь)

cancelOrder() { order.cancel() // если не выплюнуло исключений - следующие шаги }

главное что бы в этих сервисах небыло логики - только описание процесса

да

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

ERROR: S client not available

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

ну тотальное я пока считаю избыточным.... А на счет баланса - я регулярно перекидываю и выношу и не пытаюсь придумать какую-то метрику. Все субъективно

короч

ну вот я пока в поисках "идеала"

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

по факту у меня получается так, что по сути сами сервисы - вполне себе геттеры/сеттеры так или иначе. а логика +/- вся тусит в сагах

А ну быстро напомнили каким паттерном заменить атипаттерн "swich / case "

полиморфизмом?

Паттерн матчинг скаловский

А ну быстро напомнили каким паттерном заменить атипаттерн "swich / case "

половина паттернов про это

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

а вот, кстати, если синхронные ивенты считаются неотъемлемой частью бизнес-транзакции и, как следствие, транзакции БД, то кто должен рулить транзакцией? Команда?

а вот, кстати, если синхронные ивенты считаются неотъемлемой частью бизнес-транзакции и, как следствие, транзакции БД, то кто должен рулить транзакцией? Команда?

что такое синхронные ивенты?

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

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

ммм

у тебя сначала фиксация а уже потом ивенты. До фиксации ивенты собираются но на обработку не отправляются.

вот не катит по требованиям бизноса

вот не катит по требованиям бизноса

что не катит? почему не катит?

приведи пример бизнес транзакции

и что после ее "фиксации" надо делать

вот оба примера привёл: аудит и оповещения других пользователей. С точки зрения основного сценария транзакции (изменение состояния сущности, добавление/изменение VO), эта логика побочная, но с точки зрения бизнеса фиксация без аудита недопустима.

ммм

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

возможно, это не есть ивенты в терминах DDD

возможно, это не есть ивенты в терминах DDD

в терминах DDD есть ивенты7

domain event => факт, запись в твоем аудит логе если хочешь

их генерит только твой aggregate root

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

причем персистер твоего агрегата может заперсистить и ивенты = аудит который не пропадет

а если пойти еще дальше -> получаем что сначала делаем ивент стрим и по нему уже строим проекцию агрегата

но это уже event sourcing какой-то выходит

ES не рассматриваю на текущем проекте вообще. Тут надо Всё Менять, и в первую очередь, в головах.

вопрос, на самом деле, про transaction management какой-нибудь. Я хз где прочитать, поисковики нерелевантным плюются. Может, знает кто? А то в простейшем случае из app layer получается жёсткая привязка к persistence.

вопрос, на самом деле, про transaction management какой-нибудь. Я хз где прочитать, поисковики нерелевантным плюются. Может, знает кто? А то в простейшем случае из app layer получается жёсткая привязка к persistence.

Unit of work, saga.... что еще...