Архетектура проектов, как правильно организовать?

Question

[Botchal]

Здравствуйте! Подскажите, пожалуйста, есть 2 приложения на Yii2.
Они состоят из "common" (папка common с базовыми классами, например ActiveRecord, Controller и т.п.) и модулей (папка modules/) (shop, cart, user)
В этот код постоянно вносятся многочисленные изменения, как в common так и в modules.

Клиентов у нас много, причём как с разными наборами модулей так и с одинаковыми но кастомизированными (например разные actions в shop, вёрстка в user)

common общий (на данный момент мы вносим правки в каждое приложение (репозиторий) если правится common)

Нам это дико надоело.

Стоит задача, чтобы приложения использовали разный набор общих модулей и общий common

Например приложение "А" использует модули "М1", "М3", а приложение "Б" модули "М1", "М2".

Как лучше организовать работу внутри этих приложений? Модули друг от друга могут зависеть

Пока есть две идеи:
1) Оформить эти модули как пакеты, и подтягивать изменения через composer. Модули наследовать от vendor
2) Использовать git submodule, в субмодули впихнуть common и модули. Наследоваться от папки в которой сидят субмодули.

В нашем абстрактном понимании у нас есть 2 слоя-ядра, lvl1 это common, расширение фреймворка и lvl2 модули
Может быть у кого-то есть похожая ситуация, как вы всё организовали?

Answer 1

[Максим Федоров]

по-разному, по опыту я тут должен у вас спрашивать, как сделать,
но я делал модули отдельные и как композер-пакет, основной проект вообще делаю по DDD, но тут др случай, может сделать так — выделить доменное ядро, в нем сделать модули, и в каждом приложении подключать эти модули....

есть 2 приложения на Yii2. Они состоят из "common"

Не совсем понятно — как у вас в каждом приложении отдельный common? Что вы понимаете под приложением? Я понимаю под ним ровесника пакпи common —
например приложения frontend и backend

Скиньте хотя бы скрин папок — поверьте, всем плевать как там у вас (без кода тем более) и когда есть примеры крутых архитектур Симфони

Comments

[Botchal]

в common классы наследники от vendor/yiisoft/yii2, например ControllerBase, ActiveRecordBase, RequestBase, ResponseBase, ActiveDataProviderBase и т.п. + базовые классы типа LoggerBehavior, NestedIntervalsBehavior
я думал common он и в африке common, мы наверно не ясно выразились, извините

Не совсем понятно — как у вас в каждом приложении отдельный common?

почти одинаковый, я же говорю, нашли мы допустим баг в app\common\behaviors\NestedIntervalsBehavior, запушили в репозиторий проекта example.com но забыли запушить в репозиторий проекта foobar.com а может и не забыли, в этом то и проблема что он разъезжаются. Всё было хорошо, когда проект(приложение) был 1.

может сделать так — выделить доменное ядро, в нем сделать модули, и в каждом приложении подключать эти модули....

ну у нас скорее вопрос не про разделение скажем application layer от domain layer, а про то как нам править 1 баг 1 раз, а не в каждом существующим проекте копипастить исправленный код.

[Максим Федоров]

Botchal,
ну тогда:

Вариант1:
1. Сделать форк Yii2 и прямо в этих классах править их классы
2. Тут же посадить свои модули
3. Законтрибьютить в фреймворк и помочь с ошибками нам (сообществу)

Варинат2:
1. Сделать свое приложение (а-ля common) со своим неймспейсом, в нем наследовать и исправлять все классы yii2 и в нем же посадить модули
2. Превратить его в composer-пакет и использовать его в своих приложениях

В обоих вариантах как понимаете идет одно — выделение своего абстрактного common (он может быть не common, у меня например это makspass) а свои приложения будут использовать только нужное

[kpb]

Максим Федоров, если common часто меняется, не лучше его через git submodule сделать, а не через composer?

[Максим Федоров]

kpb, тут я отойду от советов — слышал не так уж это и удобно, но настаивать и советовать не буду

[Botchal]

Максим Федоров, в принципе к этому и склоняемся, но наличие отдельный пакетов композера подразумевает отдельные репозитории. Нас вот это смущает. В то время как при работе с сабмодулями мы пишем всё в одном месте (одно окно phpstorm) а при пуше гит пишет что изменился код в сабмодуле и его тоже надо запушить.

[vyachin]

делайте через composer. Если переход будет идти не разом во всех проектах, это вас немного спасет. Вы сможете переводить на новую версию common проекты постепенно.