Comments 12
Сложно каталогизировать сервисы-куски бизнес-логики, легко пропустить существующий сервис. Нужен кто-то с хорошей экспертизой проекта, кто будет за этим следить.
Ну если совсем честным быть, то в при любом подходе, на сложном проекте нужен кто-то с хорошей экспертизой проекта. Это, как мне кажется, не технический вопрос.
Да, сам факт необходимости в таких людях, конечно не оспаривается.) Я это писал к тому, что когда проектируешь какой-то кусок, постоянно приходится думать: вот придут ребята, начнут его дописывать по-своему, использовать по-своему, а кто-то не увидит и сделает похожее.
Эти вопросы всегда висят в воздухе и постоянно приходится думать, как реализовать удобное для переиспользования и сопровождения решение. Желательно так, чтобы вообще не пришлось объяснять, что это и зачем. И уж тем более, чтобы не следить потом зорким глазом на ревью, ударяя по рукам всякому, кто отклонился от твоего замысла.)
Ну во первых entity классы не всегда пишутся руками, они еще могут и генерироваться из описания к примеру. Там уже логику замучаешься втискивать. Потому имхо, если уж решили логику отдельно от данных держать, то везде, во всех проектах.
Во вторых, если понадобятся dto, то придется писать еще отдельные классы dto, а так можно взять эти пустоголовые классы и использовать в межмодульном общении.
Во третьих, логика еще подразумевает обращение к каким то сторонним сервисам. Вы для этого создали по сути тот же сервис ActivateBonusAccount со странным именем больше подходящим какому то методу. Уж тогда BonusAccountActivationService ;). И получилось, что у вас логика размазалась. Может потом в условии активации надо будет опросить еще и какой то сторонний сервис?
В четвертых, Если у меня есть UserEntity и есть UserService с методом activateUser, почему мне должно прийти в голову писать еще один сервис с таким же методом? Как можно этот сервис не заметить? Нашел UserEntity и не нашел UserService? Либо бардак с именованием в проекте, или программируете в блокноте.
Таки и что вы предлагаете? Тащить бизнес-логику в модели, как в yii, и получать классы на 10к строк и с зависимостями на половину проекта?
Не со всем согласен, но статья отличная, спасибо. DTO это все же предельный, вырожденный случай анемичной модели, откуда выброшено все, в том числе и валидация состояния.
Тут на самом деле вопрос нехитрый: если ваши модели имеют транспортную функцию, будь-то между системами, для сериализации куда-то, для сохранения в БД, они должны быть анемичнее некуда, максимум - иметь методы для сериализации и преобразования. Если это модели для бизнес-логики, то там бизнес-логика вполне себе может быть уместной, например, связанная с валидацией полей самой модели.
нужно реализовать активацию и деактивацию бонусного счета в зависимости от сложной логики смены статуса клиента.
...
Чтобы включить старую бизнес-логику в новую, вам придется сделать одно из двух: либо продублировать код со всеми вытекающими, либо запутать код, притащив BonusAccountService в зависимости нового сервиса, и вызывая его там.
Это вообще нормально, что при каждом изменении правил со стороны бизнеса нужно менять код приложения и раскатывать клиентам новую версию? Вряд-ли авторы DDD имели ввиду именно это, когда предлагали помещать бизнес-логику в модели домена.
Анемичные модели с логикой в сервисах: плюсы и минусы одного из самых популярных подходов к разработке на PHP