сценааарий!

если дословно "один из случаев использования приложения юзером"

сценааарий!

"сценарий" уже не прокатило

потому пробую другими словами

единственное тогда не понимаю фразу: "Это может быть сервис уровня приложения (знаешь же что такое юзкейс? ну вот что-то типа обработчик юзкейсов). может быть еще чего... короч ничего конкретного. "

единственное тогда не понимаю фразу: "Это может быть сервис уровня приложения (знаешь же что такое юзкейс? ну вот что-то типа обработчик юзкейсов). может быть еще чего... короч ничего конкретного. "

попробуй описать сценарий "регистрация пользователя"

полностью? от перехода на страницу регистрации?

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

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

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

Пишу app service, который создаёт пользователя, если его ещё нет и одновременно создаёт блогпост. При этом необходимо, чтобы service вернул созданный пост. Как написал я в сервисе: $user->createPost($request->get('post'), $request->get('header'), $request->get('ip')); А вот сам метод в юзере: public function createPost(string $post, string $header, string $ip) { $this->posts[] = (new Post($post, $header, new IpAddress($ip)))->setUser($this); } Полагая, что создание поста - это ответственность юзера. Но тогда у меня нет ссылки на пост, чтобы вернуть его из сервиса. Можно создавать пост в сервисе, но это вроде как не его ответственность. Можно возвращать пост из createPost, но это получается двойное назначение метода createPost. В общем посоветуйте, что делать? =\

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

так вот, юзкейс это формальное описание этого сценария. У него есть имя - "регистрация пользователя", у него есть некие требования по данным (типа должен предоставить имя, email, пароль) и у него есть сам сценарий: - временно зарегистрировать чувака в системе - выслать письмо с подтверждением - ссылка на подтверждение должна иметь возможность заэкспайриться через 24 часа

выглядит как бизнес логика

набор правил для обработки

выглядит как бизнес логика

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

ок то есть то, что я ранее определял как бизнес логику - есть юзкейс

....

нет

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

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

есть например - спецификации. Это тоже бизнес логика но на очень низком уровне

Юзкейс - что делает пользователь. Регистрируется, пишет посты, читает статистику. Бизнес логика - что делает система под капотом, чтоб юзер мог все это делать. При регистрации юзера бизнес-логика может статистику пересчитать, уведомить админа, отметить его как временно RO и ещё кучу всего, что юзер не знает

Но при регистрации юзер не знает ни о какой статистике и знать ему ненадо, что она вообще есть

о так понятнее

И об админах он ничего не знает

так вот - сервис уровня приложения - это ни что иное как реализация этого сценария: class UserRegistrationUseCase { private $users; private $notifications; public function handle(RegisterUser $data) { $user = User::awaitingConfirmation($data->name, $data->email, new Password($data->password); $this->users->add($user); $this->notifications->send(new EmailConfirmation($data->email, $user->confirmationLink()); } }

Может, какие-то баллы ему начисляются

Юзкейс может быть многошаговый

Написание поста, например, с пре-модерацией

Но при регистрации юзер не знает ни о какой статистике и знать ему ненадо, что она вообще есть

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

Не суть)

Ты человека излишним количеством деталей путаешь)

так теперь наконец понял что та фраза значила

А ему на пальцах разница между юзкейсом и БЛ нужна)

Написание поста, например, с пре-модерацией

ну это просто два юзкейса. Один - написание поста. Второй - возможность заапрувить пост. Еще надо будет возможность посмотреть список постов на апрув. Как часть второго юзкейса можно сделать пункт типа отправить нотификашку автору поста

процесс один - юзкейсов много

так теперь наконец понял что та фраза значила

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

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

А бизнес логика - какие шаги нужно сделать самой системе, чтоб юзер мог делать то, что ему нужно и на этом шаге и вообще

Пишу app service, который создаёт пользователя, если его ещё нет и одновременно создаёт блогпост. При этом необходимо, чтобы service вернул созданный пост. Как написал я в сервисе: $user->createPost($request->get('post'), $request->get('header'), $request->get('ip')); А вот сам метод в юзере: public function createPost(string $post, string $header, string $ip) { $this->posts[] = (new Post($post, $header, new IpAddress($ip)))->setUser($this); } Полагая, что создание поста - это ответственность юзера. Но тогда у меня нет ссылки на пост, чтобы вернуть его из сервиса. Можно создавать пост в сервисе, но это вроде как не его ответственность. Можно возвращать пост из createPost, но это получается двойное назначение метода createPost. В общем посоветуйте, что делать? =\

это не двойное назначение, ты можешь возвращать Post из метода createPost. Единственное что это будет нарушение CQS, но типа... иногда можно)

Пишу app service, который создаёт пользователя, если его ещё нет и одновременно создаёт блогпост. При этом необходимо, чтобы service вернул созданный пост. Как написал я в сервисе: $user->createPost($request->get('post'), $request->get('header'), $request->get('ip')); А вот сам метод в юзере: public function createPost(string $post, string $header, string $ip) { $this->posts[] = (new Post($post, $header, new IpAddress($ip)))->setUser($this); } Полагая, что создание поста - это ответственность юзера. Но тогда у меня нет ссылки на пост, чтобы вернуть его из сервиса. Можно создавать пост в сервисе, но это вроде как не его ответственность. Можно возвращать пост из createPost, но это получается двойное назначение метода createPost. В общем посоветуйте, что делать? =\

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

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

а в чем цель ADR?

та же что и у MVC разделить данные и их подготовку к отправке

сделать код читаемым и тестируемым

та же что и у MVC разделить данные и их подготовку к отправке

но если уже есть MVC и никаких отличий нет - в чем профит?

сделать код читаемым и тестируемым

но он не становится ни читаемым ни тестируемым

как называется функция что присваивает элементы массива переменным ?

export, list

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

list не функция, но не суть

list не функция, но не суть

спасибо а то забыл

Google => array to variables

как называется функция что присваивает элементы массива переменным ?

[$foo, $bar] = [1, 2]; // сверсии 7.2

[$foo, $bar] = [1, 2]; // сверсии 7.2

интересная запись, но тут проект еще 5( медленно переписывается

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

Сгенерить ссылку - это типа достать по этому вот сгенерированному id post из user-a? Или достать из закешированного в uow?

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

ADR это микроскоп?

в аналогии - да

кстати есть разница одна

в ADR responder не может обратиться в домен за данными

Сгенерить ссылку - это типа достать по этому вот сгенерированному id post из user-a? Или достать из закешированного в uow?

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

в ADR responder не может обратиться в домен за данными

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

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

да, identity map, неправильно сказал. Вообще я просто знаю, что оно там есть и его наверное даже есть возможность достать, поэтому и предположил :D А, я понял, ты про ссылку в смысле http-ссылку на ресурс поста?

hateoas вот это вот всё

в объекте Payload? соответственно 4 списка(массива)

в сценарии надо вчера я бы подгрузил в домен этой страницы или что это будет 4 домена, повытаскивал с них эти данные и упаковал в 1 payload. хотя мне это вообще не нравится

да, identity map, неправильно сказал. Вообще я просто знаю, что оно там есть и его наверное даже есть возможность достать, поэтому и предположил :D А, я понял, ты про ссылку в смысле http-ссылку на ресурс поста?

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

в объекте Payload? соответственно 4 списка(массива)

как ты будешь собирать этот список? давай усложним - предположим что детали покупателей у нас не в базе лежат, а в CRM с которой мы по http общаемся

ERROR: S client not available

ну то есть какие объекты какого типа будут за это отвечать, кто от кого зависит и т.д

детали продукта тоже могут быть в другой базе

какая разница?

домен пользователей тащит оттуда откуда должен тянуть

домен страницы естественно будет от всех 4х зависить

но так как мы ждем все это то иначе и быть не может

уточню: детали пользователей это все их данные или еще есть?

уточню: детали пользователей это все их данные или еще есть?

что значит "еще есть"?)

если ты уже сказал "все их данные"

так все или еще какие то есть в другом месте?

домен страницы естественно будет от всех 4х зависить

наваяй псевдокод

этого "домена страницы"

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

вобщем я это так понял: User::getPostById(PostId $id): array и там массив с полями, которые можно экспоузить юзверю =\

вобщем я это так понял: User::getPostById(PostId $id): array и там массив с полями, которые можно экспоузить юзверю =\

как на счет сделать отдельную сущность Author которая будет иметь ту же айдишку что и User?)

ну мол что бы разделить ответственность

как на счет сделать отдельную сущность Author которая будет иметь ту же айдишку что и User?)

а зачем? До меня что-то не доходит её назначение

типа Author будет сохранять, а User читать?

а зачем? До меня что-то не доходит её назначение

у тебя сущность User в итоге превратится в монструозную хрень которая знает все о системе. Авторизация, постинг, комментарии и прочие штуки

типа Author будет сохранять, а User читать?

забей

construct($orderDomain, $orderItemsDomain, $itemsDomain, $customerDomain), в методе getAll тащим при наличии заказов все заказы, по заказам все позиции заказа, айтемы, пользователей пакуем в payload

забей

я попробую на эту тему подумать, спасибо

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

construct($orderDomain, $orderItemsDomain, $itemsDomain, $customerDomain), в методе getAll тащим при наличии заказов все заказы, по заказам все позиции заказа, айтемы, пользователей пакуем в payload

10 заказов, количество запросов в базу и в http апишку?

10 заказов, у каждого 2 позиции, 10 разных покупателей.

или лучше не 10 а 100

что бы было посущественнее

если нужна подобная оптимизация - достаточно одного домена например OrdersWithFullDetailsDomain

из базы тащим все с использованием JOIN и подобных конструкций одним запросом, из API если позволяет тянем всех пользователей и компонуем с вытянутым из базы

таким образом у такого домена будут зависимости PDO обьект с линком на базу и обьект общения с API CRM

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

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

зачем? если тянуть из базы не через * то да в 2х местах