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

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

@theantt внутри Domain/Order тоже есть юзкейс Create, а Бизнес процесс - это несколько юзкейсов

да бы не создавать претендентов для других

Не мой скрин, но идея такая как-то

Ты же получается создаешь наружний юзкейс и там жонглируешь разными сущностями из разных контекстов? И смысл тогда от контекста. Тот же "ком грязи"

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

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

У нас все понятно, не шаримся)

Хотя с доменом на скрине вполне понятно

но, я чот сомневаюсь что кто-то прям упарывается по правильному ддд :D

но, я чот сомневаюсь что кто-то прям упарывается по правильному ддд :D

Да дело не в ДДД, дело в удобстве

@theantt внутри Domain/Order тоже есть юзкейс Create, а Бизнес процесс - это несколько юзкейсов

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

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

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

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

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

Они там и должны быть.

Не понял вопроса

Есть БЛ а есть координация

типа Domain/Order/BL/CreateOrder

типа Domain/Order/BL/CreateOrder

Прикол в том, что CreateOrder -это не домен даже)

Это апликуха

Да, но действия какие-то внутре

т.е. как помне удобно держать всё что касается домена внутри домена, не?

или обязательно надо разделить по нескольким местам код?

т.е. как помне удобно держать всё что касается домена внутри домена, не?

Что такое домен, что ты хочешь держать все внутри него? Вот есть создание заказа. Например надо создать заказ в контексте производств заказа, потом денюжки списать в контекте финансов -это все "создание заказа". В каком одном домене это должно находитьс по твоему?

вопрос вопрос 😄 я не знаю

Что такое домен, что ты хочешь держать все внутри него? Вот есть создание заказа. Например надо создать заказ в контексте производств заказа, потом денюжки списать в контекте финансов -это все "создание заказа". В каком одном домене это должно находитьс по твоему?

Так это кажется разные предметные области. По мне это не должно лежать вместе (но я не знаю, я баклажан)))

Потому что по тому же ДДД это не одно и тоже. Соответственно не будет единого языка

Так это кажется разные предметные области. По мне это не должно лежать вместе (но я не знаю, я баклажан)))

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

Скорее тогда отдельные сущности по предметным областям и какой-то агрегейт с транзакцией

Скорее тогда отдельные сущности по предметным областям и какой-то агрегейт с транзакцией

Ну я сам грамотно не могу ответить (да и не знаю), но да как то так. Это как раз по скрину выше

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

если подумать, то должна быть какая то штука снаружи ``` // begin transaction if ($balance < $orderCost) { // rollback return; } $orderDomain->createOrder(123) $balance--; //commit

если подумать, то должна быть какая то штука снаружи ``` // begin transaction if ($balance < $orderCost) { // rollback return; } $orderDomain->createOrder(123) $balance--; //commit

Так не надо делать

а как?

Все эти balance++, balance--

да это условный код )

понятно что там сервисы будут какие-то, которые отвечают за списание средств

и всё это должно быть в рамках одной транзакции

Все это должно быть либо атомарно, либо с блокировкой на чтение

Иначе будет неправильное списание

Тогда будет одна папочка где будет CreateOfferCommand CreateOfferHandler ChangeOfferCommand ChangeOfferHandler

CreateOffer/{Command, Handler}

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

В скрине выше, что есть Домен Order (там правда нет отдельных экшенов), а есть еще процесс Создать заказ, который более глобальный

CreateOffer/{Command, Handler}

Да так и делаем, только /UseCase/Create/{Command, Handler} . Вообще вопроса никакого не было, это Муравей предложениями засыпал)

Все это должно быть либо атомарно, либо с блокировкой на чтение

Это можно сделать оптимистичнй блокировкой

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

если подумать, то должна быть какая то штука снаружи ``` // begin transaction if ($balance < $orderCost) { // rollback return; } $orderDomain->createOrder(123) $balance--; //commit

Должено быть что то так: $financeHandler->buyOrder($cost, $orderId), $manufactureHandler->createOrder($orderId, $orderParams)

$orderId должен откуда-то браться? )

$orderId должен откуда-то браться? )

Uuid,можно вернуть из одного из хандлеров, или какой то генератор идентфиикаторов

все таки я думаю правильно. операции создания ордера и собственно покупка(оплата) несколько разные штуки

$orderId = $manufactureHandler->createOrder($orderParams) $id = $financeHandler->buyOrder($cost,$orderId ),

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

все таки я думаю правильно. операции создания ордера и собственно покупка(оплата) несколько разные штуки

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

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

Но мы пока не доросли, можно и гавнять, чтобы не обосраться

А потом уже фиксить и быть крутым по месту

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

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

получится цепочка команд

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

Это немного шляпно и не прозрачно

ну да, такое себе

в модульном монолите я думаю не зазорно дернуть сервис из другого модуля 😄

хотя идеологически это хуевое действие :D

в модульном монолите я думаю не зазорно дернуть сервис из другого модуля 😄

Тогда это уже не модульный монолит)

А просто монолит

Тогда это уже не модульный монолит)

если дергать публичные методы модуля (а его рассматривать как домен)... 🤣🤣

если дергать публичные методы модуля (а его рассматривать как домен)... 🤣🤣

Ну вот ты ржешь, а в этом и смысл)

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

Тут просто еще вопрос правильного размера контекста

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

Короче вопрос не простой, ну по крайней мере для меня

согласен, чот как-то сложновато

У меня например основные сложности, что делать если сделать асинхронное создание заказа и списание денег. А если денег нет, значит надо какую то конпенсацию, отмену заказа, а если упадет очередь или какая то ошибка, как это обнаружить. Значит надо сагу (епт что это такоеXD XD XD ) , какие то проверку по крону наверное. Проще в транзакцию и синхронно)) так и гавняю

Ну, исходить из задач конечно. Зачем создавать заказ асинхронно, если это операция вставки данных в таблицу? непонятно )

У меня например основные сложности, что делать если сделать асинхронное создание заказа и списание денег. А если денег нет, значит надо какую то конпенсацию, отмену заказа, а если упадет очередь или какая то ошибка, как это обнаружить. Значит надо сагу (епт что это такоеXD XD XD ) , какие то проверку по крону наверное. Проще в транзакцию и синхронно)) так и гавняю

Первое правило - делай надежно Второе правило - делай красиво

Ну, исходить из задач конечно. Зачем создавать заказ асинхронно, если это операция вставки данных в таблицу? непонятно )

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

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

транзакции могут быть многоуровневыми. если у тебя 1 бд )

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

Блин там с одноуровневыми проблем хватает, а вы ещё многоуровневые хотите )

Это можно сделать оптимистичнй блокировкой

На большой нагрузке ты быстро поймёшь что это вообще не вариант

транзакции могут быть многоуровневыми. если у тебя 1 бд )

Это понятно, но это не гуд, так как большая внешняя тразакция - основная, и за это время могут еще что то делать и шанс фейла блокировок больше

к примеру юзер на сайте сформировал корзину, там 3 товара. Два из них есть на локальном складе, а 1 по запросу доставляется. тут уже надо спрашивать у бизнеса, че делать если корзина не оплачена? лочить эти 2 товара на локальном складе или нет? надо ли делать запрос на доставку третьего в магаз? Или всё это делать тока после оплаты заказа? В итоге у нас или просто будет запись в бд, или с походом в сторонний сервис, чтобы сделать там заявку