Про фреймворки и сервисный слой

"Слайды на 100 страниц. Извините))" - классика))

Дмитрий молодец!
Классное видео, очень просто и полезно!

Здравствуйте, Дмитрий!

Очень увлекательный доклад, спасибо.
Есть один вопрос:

Что делать, если бизнес-логика зависит от юз-кейса?

Приведу синтетический пример:

class Post
{
    public function publish()
    {
        if($this->status === self::IN_MODERATION)
        {
             throw new \DomainException('Not allowed');
        }
    }
}

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

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

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

Как Вы считаете? Спасибо

Не будем смотреть на тесты.

Вы можете вызвать publishByAdmin там, где это не стоит делать и с точки зрения DDD инвариант будет нарушен, потому что метод модели семантически зависит от юз-кейса

Дмитрий, спасибо за то, что вы делаете!

Спасибо за доклад, Дмитрий!

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

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

Куда в этом случае ложить эти проверки и на каком уровне защищать это бизнес правило, если оно неделимо?

Дмитрий, есть ли в планах провести мастер-класс или написать статью по сагам? Интересует saga orchestration.

Очень крутой доклад. Спасибо.

Есть ли существенные минусы у Доктрины?

Есть ли сейчас достойная замена Доктрине? Какая-либо другая библиотека, позволяющая писать код по DDD. Чтобы уровень удобства был не меньше чем у Доктрины.

Спасибо )

1. В чем профит создания связи с помощью Member/Id, почему не передаете непосредственно объект Member в конструктор лота? Ну и соответственно memberId - строка, вместо ManyToOne?
2. Если работаем со ставками через лот, то как быть, если, к примеру, надо вывести постранично список всех ставок? Работать с массивом объектов может быть накладно

1. А с доктриной? Все-таки в примере используется она
2. Т.е. для вывода данных доменные сущности не используются? В таком случае в каком слое будет находится код, реализующий эту функциональность?

Под UseCase (если прямо по тексту то что-то типа UseCase\SignUp\Request) подразумевается namespace для объединения Command и Handler или я где-то пропустил все-таки отдельный класс под UseCase? В коде презентации в контроллерах же просто везде хендлер дергается с передаваемой ему командой!

А если вот у меня например use case можно обозвать как GetRate, "Получить цену". То есть я хочу в API, web-морду, CLI или еще как-то вернуть некую цену на мой товар. Наверное, тогда стоит именовать классы GetRateQuery и GetRateQueryHandler соответственно. И у GetRateQueryHandler должен быть, наверное, не handle(): void, а что-то типа getResult():mixed ?

Да у меня тут больше вопрос был про handle():void, если для Command, и hande():mixed для Query. То есть нужно ли разделять хендлеры (по их интерфейсам имею ввиду) для Command и для Query, ибо, судя по всему, в ответ на запрос все-таки нужно что-то более существенное чем void вернуть :).

Спасибо!

Дмитрий есть ли в планах рассказать о Specification pattern и в частности применение его в репозиториях для выборки объектов из базы данных?

Получается мы в полностью отказываемся от фреймворковского взаимодействия с базой и его ActiveRecord (или что там есть во фреймворке)?

Курто! Спасибо большое за вашу работу. У вас где посмотреть список полезной литературы на сайте, чтоб не читать все подряд?