Я сейчас рефакторю проект на основе yii2 фреймворка. По сути его можно было бы переписать на Symphony и попутно изучать этот новый для меня фреймворк, но я решил попробовать потихоньку учиться применять новый для меня подход DDD и все это дело делать с Yii2 под капотом. Понятно, что этот фреймворк считай не располагает к такому подходу, но на сколько я понимаю, при нужном умении, DDD как раз вообще не должен завязываться на фреймворк.
Сейчас постоянно сталкиваюсь с проблемами, что когда пишу какой-то компонент так или иначе он завязан на фреймворке. И я честно говоря не понимаю, как писать не завязываясь.
Вот, допустим, пишу я фабрику, фабрику которая возвращает мне модель данных. В Yii2 модель это либо просто класс Model не завязанный на базу данных, в котором есть методы load для загрузки данных в модель, validate, rules с правилами валидации, save и так далее, или есть ActiveRecord модель считай с тем же набором свойств и методов, так как в глубине она тоже наследуется от Model, только она завязана на базу данных, то есть при получении экземпляра ActiveRecord он заполнен данными из базы.
Вот эта фабрика по сути не должна быть завязана на фреймворк, так как, по сути, она должна быть где-то в домене. Но в этой фабрике я по идее должен создавать экземпляры моделей Model или AR, делать, например, $model instanceof Model или AR, чтобы понимать что мы вообще работаем с тем что нужно и там же собственно вызывать их метод load, чтобы подгрузить туда нужные данные. А следовательно появляется привязка к этим моделям и фреймворку.
Вариант который я вижу - вообще отказаться от использования Model и ActiveRecord, а делать свою кастомную модель, которая по фату будет делать все то же самое и у нее будет свой интерфейс на который мы и будем полагаться в фабрике делая $model instanceof SomeModelInterface.
Но тут надо понимать, что это значит просто переписывание логики фреймворка вручную. И встает вопрос нафига он вообще тогда нужен, если я буду все его удобности в виде моделей с логикой сохранения, валидации, загрузки данных и прочего, переписывать? То есть я по факту должен буду создать интерфейс для этих моделей описывающий все что нужно, типа тех же методов load,, save, validate, getErrors и многих других, потом все это реализовать в базовом классе модели и от нее уже наследовать все другие модели, экземпляры которых создавать через фабрику. Можно наверно вообще просто скопировать все что есть в Model фреймворка, потом типа это назвать своей моделью и использовать)))
Да, я после этого смогу взять, вырезать это дело из проекта и запихать в Symphony например, но опять же вопрос - зачем? если от фреймворка и так ничего не используется. Максимум роутинг и контроллеры?
Что вообще от фреймворка в конечном счете остается и в чем тогда смысл на его основе что-то писать, если по факту это замедлит разработку в разы? То есть мы когда-то писали на cms, потом это стало зашкварно (все мы понимаем почему), перешли на фреймворки, теперь и от них уходим почти в сторону чистого php?)
При работе с Yii2 изначально стоит выносить любые компоненты в обертки, и их использовать по проекту, так вы легко сможете отвязаться от реализации, используя интерфейс обертки.
Что касается DDD при работе с Yii2 и моделей - идеально было бы разделить приложение на различные слои, полностью отделив из средних слоев любые зависимости Yii2, но модели я бы не стал наделять интерфейсом, в этом плане вам поможет создание своего репозитория, в котором можете спрятать любые методы на выборки при помощи юшных моделей, а наружу отдавать уже самостоятельно смапленные Entity и уже их наделять интерфейсами и использовать дальше, но это именно для выборок конкретных записей. Если вам необходимо выбрать несколько записей - почти аналогично используюте Entity, создаете свою кастомную коллекцию которая имплементирует встроенные интерфейсы Iterator и Countable. Для их разделения можно использовать базовый класс как родителя, а дальше создавать нужный класс коллекции для смапленных Entity.
Но вся ваша идеальная задумка DDD с Yii2 легко развалится при использовании ActiveRecord и базовых моделей - в них сразу пихается и валидация, и каст, и обработка поведений на сохранение/обновление/удаление, так еще в старых проектах еще и триггеры навешивают часто. Может стоит подумать, нужен ли вам вообще тут DDD? Если это сделано с целью отвязаться от фреймворка в любой момент - то используйте для моделей Entity, Collection и выносите сразу все в репозиторий, легко сможете мигрироваться на тот же симфони. Безболезненного перехода не бывает и так или иначе что-то да придется переписывать, но все сможете это сделать просто поменяв код ваших репозиториев и контроллеров с реквестами.
А вы не в курсе, можно ли где-то подсмотреть такую архитектуру? Может где видели в доступе, например, в блоге или еще где? Просто по описанию сложно представить реализацию, иерархию сущностей, что куда для чего и от кого)
ваше направление и мысли полностью совпадают с моими, поэтому дополню то что уже писал k2lhu
DDD это больше про агрегаты и контекст, может вам нужна гексогональная архитектура и все что связанно с clean architecture. Принцип простой, ваша бизнес логика не должна зависеть от деталей реализации, попробуйте написать код без фраймворка например сохранение , отображение простых сущностей, пользователей. У вас будет репозитории не работающие с базой а просто Mock-репозитоиии, но реализующие интерфейсы. Так у вас появится Domain layer и очень тонкий Infrastructure Layer. Далее попробуйте реализовать бизнес логику и сценариции для работы с вашими сущностями, например регистрация пользователя, у вас появится Application Layer. Далее вам нужно организовать контроллеры или модули который будут отображать элементы интерфейса, вы создадите контролеры, вьюхи, модули(виджеты) и тд. например форма регистрации пользователя, так у вас появиться Presentation Layer. Далее вы переведете на динамику ваши репозитории, адаптеры и реализуете сохранение ваших пользователей в базу с помощью Activerecord или DataMapper. Так появиться Infrastructure Layer.
Плюсы, бизнес логика не зависит от фраймворка, на каждом этапе слоя вы можете подключать фраймворк на уровне как минимум в Infrastructure Layer, Presentation Layer. При смене фраймворка будите менять только их.
Тесты можно внедрять без проблем особенно на уровне домена и бизнес логики.
Золотые слова дядюшки Боба:
Когда вы пишите приложение на фраймворке для заказчика вы гарантируете разработку приложения и его поддержку в течении жизненного цикла, но какую гарантию дает вам разработчик фраймворка?
Так там попробуй в кучу говнокода засунуть новые модули) Это когда ты скачиваешь чистый фреймворк как говорится в одной коробке и на его основе пилишь приложение это да) А когда у тебя куча кода написаного через одно неприличное место и его нужно отрефакторить, вот это вот решение с попутным изменением каркаса, тут нужно сто раз подумать) Потому что в целом переписать это все будет не так просто)
А что там вообще нового и полезного, что делает его лучше старой версии? Что-то в архитектурном плане поменялось? Или те же AR и связанные модули?
Sergey Ilichev, хз - я евангелист zend/laminas. уж больно этот yii странный - у котроллеров есть суффикс, у моделей нет - почему мне так выяснить и не удалось + куча магии + перегруженные методами модели - не мое)) вообще у них какая-то стагнация - изменений мало, все подались в семейные дела) но вроде как у них есть план и они его придерживаются)
Средний
