DDD вообще и в частности если стоить на основе yii2?
Всем привет!)
Есть вопрос про DDD.
Начал изучать эту архитектуру, почитал статьи, посмотрел видео, в общем не мало материала перерыл на эту тему. Сам сейчас больше всего пишу на Yii2 фреймворке.
Вот есть у нас модель. В yii2 это ActiveRecord (чаще всего), что это из мира DDD? Это entity? Или иначе, что есть entity в концепции Yii2? AR содержит описание полей модели и вроде подходит на эту роль больше всего, но в то же время, вообще даже не удовлетворяет концепции single responsibility и содержит разную логику не присущую entity.
Нужен ли вообще AR в DDD? Как его использовать? Как некоторый сервис? Или вообще не использовать? А те же связи где хранить тогда?
Может можно типа переписать генератор моделей, так чтобы генерировать просто модели с набором полей, без привязки к AR, а для доступа к базе типа использовать не AR, а просто query builder?
Может кто-то видел Yii2 проект с развернутым DDD, то есть с готовой архитектурой, генераторами? Хочется посмотреть архитектуру и понять, как вообще это должно выглядеть. Некоторые вообще пишут, что логику нужно держать в сервисах, хотя в большинстве статей, что я читал и в видео, которые смотрел, говорят, что в сервисах нужно держать только логику не подходящую ни для одной entity.
Реализаций много, все они различаются. Эталоном можно считать книгу Эванса. Вместо сервисов можно использовать CQRS, которые непосредственно взаимодействуют с репозиториями. У меня логика, которую нельзя реализовать в корневой сущности агрегата, помещается в репозиторий, но это решение очевидно.
А что на счет именно Yii, вы знакомы с этим фреймворком? Например, что по логике есть AR и нужно ли вообще его использовать? Я например, считаю, что нужно написать генератор и, чтобы в проекте уже вся структура генерировалась, для этого нужно хоть какое-то понимание получить о структуре кода на чем-то близком к тому, с чем работаешь. Просто сейчас не понимаю, что от фреймворка оставить, а что не использовать. Суть yii фреймворка в том, что ты генеришь через генератор все модельки (обычно наследованные от AR) и потом во всем проекте используешь их (запись и чтение из бд, валидация, чаще всего основная бизнес логика там же), и я совсем не понимаю, как без этих моделек жить, но понима, что они в эту концепцию не вписываются. Это вроде и entity и сервис и е место для валидации (кстати, а где валидацию по канону нужно располагать?).
Если не трудно, объясните, на счет валидации, работы с бд (через модель как в AR), связей моделей (построенных на основе связей в базе данных), где это все должно быть? Тоже в entity? То есть entity должно хранить все то же что и AR или все таки тут не такая солянка?
first-programmer, С Yii не знаком, поэтому сказать ничего не могу об AR. Конкретно по DDD: домен точно не может зависеть от AR. На инфраструктурном уровне можно использовать средства конфигурирования БД, поэтому здесь можно реализовать функционал репозиториев, интерфейсы которых описаны в домене и работать внутри реализации непосредственно с БД. На этом уровне можно сконфигурировать сущности домена для конкретной БД.
first-programmer, валидация в приложении yii. Сами entity в этом случае дублируются: если используется cqrs, то для сущности user создаются команды: CreateUserCommand, RemoveUserCommand которые дублируют нужные поля из entity user. В команды добавляется валидация. Такую концепцию я извлек из eShoppingOnContainer, который описан в блоге майкрософта и из других звездных проектов гитхаба (4000 и выше). Это для asp.net, но не думаю, что подход будет сильно отличаться для yii
Средний