Я вас понял, спасибо. В общем в сущностях у нас данные и код для соблюдения инвариантов (согласованноси данных). В сервисах у нас все остальное поведение, включая обработку событий сущностей.
Мне это не близко. Напоминает процедурную декомпозицию: сущности — структуры данных (пусть и с инвариантами), сервисы — поведение. Это юзабельно, но мне не заходит, как то слишком мало при таком подходе могут сущности, мало инкапсулируют.
Резюмируя по теме статьи: получается, что если при использовании сеттеров инварианты не страдают, то ничего плохого в их использовании в сущности нет?
С EventBus разобрались, все кто ее используют это должны быть в Application слое. А где тогда должна быть бизнес логика, которая юзает зависимости, например, если при рассчете времени доставки заказа нужно опросить внешнее API? В приложении этот API предположим, представлен как DeliveryService внутри которого http клиент. Можно ли его внедрять в доменные сервисы?
И все таки я еще про внедрение репозиториев в доменные сервисы хотел уточнить? Можно ли их туда внедрять или нет? Если нет, что тогда могут доменные сервисы? Если да — почему тогда нельзя внедрять репы в сущности?
Под бизнес-сервисами имею ввиду Domain Services. Если следовать логике, что домен не должен ничего знать о приложении, то тогда внедрение зависимостей типа EventBus в Domain Services будет нарушением правил чистой архитектуры? В доменные сервисы много раз видел как внедряются репозитории, это нарушение?
А можете объяснить, каковы последствия этого нарушения? Связь же можно сделать посредсвом интерфейса, это тоже плохо? К тому же помимо сущностей есть бизнес-сервисы, это тоже часть БЛ, но в них зависимости все внедряют, в т.ч. и EventBus. Это разве не будет нарушением?
Отсюда и проблема анемии сущностей. В том виде, в котором сейчас принято работать с Doctrine ORM: «не надо туда ничего внедрять, кроме того, из чего состоит сущность», проблема анемии останется там где и была.
Тут уже писали — было поведение в сущности, изменились требования, теперь это поведение требует зависимость, поведение переезжает в сервис.
Я в целом с вами согласен, но для меня есть одно препятствие (если говорить по sf и Doctrine ORM): для бизнес-логики нужны зависимости, почти всегда. Если в сущностях оставлять код работающий только с состоянием сущности и не использующий зависимости, то кода в сущности будет немного, отсюда и возможное вырождение в DTO с геттерами и сеттерами. Препятсвием является невозможность внедрения зависимостей в конструктор сущностей в Doctrine ORM. Поэтому не использую эту ORM по собственному желанию, больше по необходимости (если она уже есть в проекте).
А я не согласен. Я бы подумал, может и в сущность зависимость добавить, например если эта зависимость используется в большинстве методов сущности, а в isDelivered() три четверти кода используют состояние сущности.
Так речь не об Order, а о User и генерировании пароля. А так согласен, в ООП одним из критериев распределения поведения является использование в этом поведении стейта, грубо говоря первым какндидатом на поведение будет класс, у котого есть стейт, с которым работает это поведение.
Да мокаю, здесь проблемы нет. Просто в setUp() локатор пересоздаю и нужные для теста моки туда добавляю. Можно и сам локатор замокать, с этим тоже проблем нет, но эта штука крайне простая, поэтому добавляю в него моки сервисов.
А я думаю, что развязывание publish() и части описанного (логи, уведомления и пр., кроме сохранения в БД и безопасности) надо решать в том числе с помощью паттерна «Наблюдатель» и шины событий: внутри publish() надо генерить в шину событие. Проверка прав — это пусть контроллеры делают или middleware.
Я считаю, что генерация пароля входит в «обеспечение предоставления информации для аутентификации», вы считаете, что не входит. Какого-либо правила, позволяющего однозначно сказать, кто прав, у нас нет. Тупик. Поэтому и работаем как получается, но плохого в этом ничего нет, работа такая)
Мне это не близко. Напоминает процедурную декомпозицию: сущности — структуры данных (пусть и с инвариантами), сервисы — поведение. Это юзабельно, но мне не заходит, как то слишком мало при таком подходе могут сущности, мало инкапсулируют.
Резюмируя по теме статьи: получается, что если при использовании сеттеров инварианты не страдают, то ничего плохого в их использовании в сущности нет?
И все таки я еще про внедрение репозиториев в доменные сервисы хотел уточнить? Можно ли их туда внедрять или нет? Если нет, что тогда могут доменные сервисы? Если да — почему тогда нельзя внедрять репы в сущности?
А можете более подробно разъяснить, в чем именно заключается утеря?
Какие вы видите новые пути для возникновения ошибок?
Тут уже писали — было поведение в сущности, изменились требования, теперь это поведение требует зависимость, поведение переезжает в сервис.