одно дело обновить модуль через компосер и накатить миграции, другое это протестировать систему с новой версией модуля, ведь может возникнуть ситуация что модуль может вызвать неработоспособность сайта из за конфликта с другими модулями, кривой миграции или кода, т.д. Что думаете по этому поводу?
как вариант создать ветку в гите feature/my-feature - чисто для кода feature/my-feature/data - миграции
если разработчику нужны миграции он сливает себе ветку с данными и устанавливает миграции
я использую схему разбиения пакетов по глобальному функционалу: CMS(базовый функционал, с установкой работает админка, публичка, модули: меню,слайдер и т.д.), eShop (интернет магаз, модули: витрина, каталог и т.д.), далее по такой же схеме могут быть Блог, Форум, Галерея и т.д
при установке все это дело находится в vendor, если в пакете находится ошибка я делаю коммит из пакета, так как при установке из компосера там находится репо гита, при комите создаю ветку что то вроде fix/any_bug и отправляю в репозиторий, то же самое с features. дальше кто отвечает за данный пакет уже принимает решения включать в релиз или нет.
не очень практика, мы щас ее используем)), дело в том что одно ядро на всех будет принудительно обновлять функционал для всех сайтов, и если кроме шаблонов в проекте разработан какой то модуль, расширен системный функционал или еще что то, то это при обновлении может вызвать сбой так как обновляя ядро вы должны учитывать индивидуальность каждого проекта, если проекты разрастутся следить за этим будет невозможно. Соответственно подтягивайте ядро для каждого сайта через компосер персонально, обновил, проверил, выкатил на сервер. Но если у вас один сайт и вы организуете что то вроде мультисайтовости то это уже другая тема.
как у нас было: site.ru/public/index.php, site.ru/vendor/company/core/src/Module/Menu/tpl/default.php, site.ru/public/Module/Menu/tpl/defaul.php
index.php - принимает все запросы подключает автолоадер и запускает ядро, ядро использует модули но при генерации шаблона используется принцип поиска аналогичного в каталоге проекта site.ru/vendor/core/src/Module/Menu/tpl/default.php, если он существует то будет подключен, в противном системный
вам нужно именно в корне для css,js,images ? как вариант перекидывать файлы из vendor пакета в публичную директорию сайта, либо ручками либо скриптом https://getcomposer.org/doc/articles/scripts.md
На счет DDD, UserService - Service - Сервис. Содержат бизнес логику приложения. Все зависимости поступают из вне. Зависят от абстракций. Разве не оно?
По поводу доктрины, очень она громозкая, так как я разрабатываю отдельный компонент для системы которая доктрину не использует то тянуть доктрину для ради одного опционального пакета не очень гуд. Если есть менее объемная библиотека для реализации datamapper то можно было рассмотреть использование.
вот смотрите $User->id = 1; $User->name = 'vova'; $User->update(); метод update содержит некую логику позволяющую подготовить данные для обновления в базе данных, в итоге будет задействован некий qeurybuilder который сформирует запрос к базе (в зависимости от подключенного драйвера mysql, postgre и тд), выполнит его и отдаст результат успешно или нет. Так вот если есть возможность то qeurybuilder нужно подменить и тестировать нужно изолированно только метод update. Так как qeurybuilder идет вместе с фрамеворком и протестирован разработчиками. Если у вас используется dependency injection то такие зависимости легко глушатся при тестах. Repository - посредник между сущностями и хранилищем и как раз содержит CRUD, подмена хранилища при тестах позволяет протестировать репозитории без подключения к базе.
префикс добавляют для группировки таблиц по конкретному функционалу это облегчает работу с ними когда таблиц очень много. Префикс у полей полезен для уникальности названия полей при выполнении запросов, нет необходимости присваивать псевдонимы.
на самом деле клиентам ваш код не нужен, им нужен результат работы, даже если у вас будет идеальная архитектура, SOILD, тесты и т.д. это никто не оценит, клиенту пофиг что под капотом.
не разбирался с работой компонентов в Yii но интересно как там assets файлы используются ведь не будет приложение напрямую из каталога vendor их подключать?
обычно схема такая:
1. Для каждого проекта есть git репо, добавляется post hook на Jenkins сервер
2. На сервере под управлением Jenkins создаются проекты, каждый проект делает: 1)обновляется через гит, 2)обновляет зависимости, 3)тестирует проект, 4)заливает на удаленный сервер
3. При коммите в мастер ветку или слиянии с мастер веткой разработчиком, уходит запрос на jenkins и тот делает свою работу. Для вашего случая 1 и 4 обязательные
Вместо jenkins можно использовать любой облачный CI сервис, я использую codeship
для этого и нужен Continuous Integration сервер который а) подтянет через гит проект б) обновит компосер в) протестирует проект г) зальет файлы на рабочий сервак
