- заказ
— выполнен и оплачен
- курьер
—  имеет меньше 20 активных заказов
- заказ - передать - курьер
Есть ли тут какое-то решение приложения или может быть что-то используется не из домена? Вроде нет.

ещё раз сошлюсь на статью Хорикова:
> We have a nice separation of concerns here: business logic is attributed to the domain model, while interactions with the external world - to the application service.

Понятно, спасибо. Я просто прикинул, что если брать несколько копий приложений, то правила именно 20 заказов, и например выдавать только оплаченные - можно менять от приложения к приложению.

Видимо моя логика не в ту сторону шла)

Короче в одно ухо влетает, из другого вылетает... https://emacsway.github.io/ru/service-layer/  читал уже не раз и бесполезно )))

Апп не содержит бизнес правила, значит мой довод разбит в щи

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

👏 годный блог

а шо там за сбои происходят?

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

ну, лёг пейментовый шлюз, например

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

ну смари, на примере страйпа

есть процессинг асинхронный, есть синхронный на стороне сервера

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

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

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


это всё редкие кейсы, но всё же иногда стреляет

а, ну это всё нюансы и out of order messaging, это всё решается

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

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

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

Чет вообще не понял для чего наворотили ивенты и асинхронщину с такой простой и не конкретной штукой.
Лочим курьера с его (КоличествоВязтыхЗаказов) и сам заказ (оплачен/неОплачен, отвественныйКурьер). Меняем кол-во взятых заказов +1, прибавляем отвественное курьера к заказу

Кстати, VO тоже может иметь логику тк VO относятся к домену

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