magicoder писал(а):Знаю, что подобные темы уже были.
Да весь этот раздел на форуме. Вы уже все соседние темы прочитали?
magicoder писал(а):Однако, решил открыть данную тему, чтобы люди, который "знают толк" в построении правильной архитектуры приложения (сайта) на yii2 могли поделиться примерами кода.
Архитектура - тема об абстракциях, а не о реализации. Идеи и принципы в ней одни и те же независимо от языка программирования. Потому и разрозненная и на форуме не очень распространённая, что это отдельный пласт информации, одним фреймворком и языком не ограничивающаяся.
Язык PHP сам по себе никогда не подстёгивал разработчиков к построение архитектуры, так как даже нормального ООП в нём до последних лет практически не было. В отличие, например, от Java, где паттернам и энтерпрайзу учат "с пелёнок". Поэтому изучать всё это на примере PHP нет смысла. А на Yii2...
Yii2 - это Yii1, переписанный на пространства имён. Сильных архитектурных изменений в нём при переписывании не произошло. Соответственно, имеем в нём сейчас то, что было "модным" ещё в "лихих нулевых" со времён первой версии: свои подходы к геттерам и сеттерам, публичные поля, синглтоны, статические методы, сильную связанность из-за вездесущего наследования и экономии на классах, несовместимость с новыми PSR - то есть своеобразный "коммунизм" с самозамкнутостью и железным зановесом. Поэтому-то с такой весьма странной внутренней архитектурой он и выглядит белой вороной на фоне остальных.
К чему приводят внутренние архитектурные странности? Хорошим стилем можно и на Wordpress приложения программировать, если есть соответствующие навыки как при этом победить изнутри сам Wordpress. Но в какой-то момент времени число мешающих факторов со стороны этой CMS зашкалит критический уровень, терпение закончится и разработчик примет решение перейти на более удобную внутри CMS или фреймворк. Такая же ситуация и с "лёкими" фреймворками и дешёвыми автомобилями. Сначала получаем удовольствие от внешнего вида и всем советуем. А потом по необходимости залазием под капот во внутренности, а там... А через год вечного ковыряния, залатывания дыр и доводки напильником в гараже хочется выбросить это всё и купить что-то покруче.
magicoder писал(а):...построении правильной архитектуры приложения (сайта) на yii2
И из-за лёгкости изучения Yii2 у многих самый первый в их жизни. Symfony и прочие вещи для новичков кажутся слишком сложными, да и лень документацию на английском читать. А простой Yii2 для них в самый раз. Да и разработчиков на нём не сильно много, так как фреймворк более как продукт любительский, сделанный в свободное время несколькими разработчиками. Целенаправленного маркетинга и сопутствующей инфраструктуры у него нет. Поэтому если учесть, что в Yii2, наверное, 70-90% новичков, которые только-только начинают изучать ООП после процедурных CMS, то обилия статей и прочей информации о лучших практиках среди его пользователей найти весьма сложно. Только статью от 2Gis на Хабре и, возможно, ещё пару блогов. А так даже более-менее сносное ООП в проектах на Yii2 почти не встречается.
Соответственно, ищите информацию об архитектуре по тем языкам и фреймворкам, где много народа и где эта архитектура давно уже есть. Да и форум - это больше просто для подсказок новичкам от новичков.
magicoder писал(а):Поэтому, если Вы сильны в архитектуре и можете поделиться с сообществом кодом, как лучше организовать модели и контроллеры, как оформить классы сервисов и репозиториев, уменьшив тем самым зависимость от фреймворка - прошу поделиться опытом в данной теме.
В сервисах, репозиториях и все этих вещах ничего особенного и сверхъестественного нет. Это всё естественным образом вытекает из исходных принципов того самого ООП, которое придумали уже черт знает когда и которое всем лень учить. Это целая парадигма, а не только синтаксис. Если перекинуть все свои процедуры и функции в классы, то объектно-ориентированным наш код сам по себе не станет.
Конкретно в этом примере по обобщающему паттерну наш "контроллер" должен только принимать информацию из одного места и перекидывать в другое. На то он и контроллер, что должен только контролировать процесс, не делая ничего самостоятельно. Принял GET или POST-параметры и закинул в модель или в рендерер. "Модель" должна моделировать сущности и процессы предметной области (домена). Сущности с их поведением описываются в "сущностях", а вспомогательные операции - во вспомогательных объектах - "сервисах домена". Иногда контроллер у нас не одно действие выполняет, а порой по несколько объектов заполняет и их друг с другом связывает. Ну или другие вещи. А из контроллера нужно этот код куда-то вынести, чтобы контроллеры оставить пустыми. Это и будут у нас "сервисы приложения".
Если у Вас в коде есть разделение на ядро и обвязку, то при миграции на другую БД или фреймворк нужно будет только поменять обвязку. А если нет - то придётся переписывать весь код. Соответственно, делаем независимое от фреймворка ядро на чистом PHP, а весь фреймворковский код помещаем в обвязку. На этом многослойная архитектура и построена. Слой UI представляет собой контроллеры, шаблонизатор и формы ввода. Кода с логикой там нет. Только представления, формочки и клиентская валидация. Контроллер вызывает методы операционного слоя (уровня приложения). Слоем доменной модели является само вышеупомянутое ядро с интерфейсами адаптеров обвязки. В нём весь код. Слоем инфраструктуры являются классы реализации этой обвязки. То есть переходники (адаптеры) для доступа к базе данных, мэйлеру, хешерам паролей и прочим фреймворковским штукам.
Весь секрет - инкапсуляция изменчивости: делаем независимое ядро, взаимодействующее со внешним миром через адаптеры. Нужно что-то поменять - просто переписываем адаптер.
За полгода углубленнного изучения независимых архитектур осознал, что программировать независимый код несложно. Просто многим лениво. Если хочется именно на примерах, то на чистое ООП и независимость от фреймворков идёт весь упор в девятнадцати примерах
интенсива. Там пять дней с этими примерами по четыре часа объяснения и практики и ещё пятичасовой мастер-класс по приложению с сервисным слоем на Yii2. Можно вписаться на следующий поток или уломать автора продать записи прошедшего.
magicoder писал(а):Это очень важно, чтобы такие примеры были в одной теме, потому-что вся информация разрознена и приходится собирать ее по кусочкам по всему интернету и на форуме.
За несколько лет всё подробно описано в статьях, слайдах, книгах и видео. Кое-что есть и на русском языке. Это естественный отбор. Кто осилил это всё собрать и освоить, тот становится архитектором. Кто не осилил - не становится.