Вопросы по Clean Architecture?

Хочу пруфлинк, от куда такая инфа, что сущности не могут быть моделями ORM и иметь внешние ключи.

- в том то и фишка clean architecture вы проектируете приложение и пишите его не опираясь на ORM , инфраструктура вторична при данном подходе.

Как договорится с людьми использующие разные подходы?

в вашем тексте уже куча ошибок, начните с себя

Шаблонизаторы ещё актуальны?

поддерживаю., пхп как шаблинзатор не дает строгие ограничения как twig например, поэтому позволяет писать что попало

Как правильно работать с git на хостинге?

деплой через git прямо на сервере это КОСТЫЛЬ
там не будет сборки, тестирования проекта

Начинать нужно с составления ТЗ или что-то другое?

Никита Никитин,
давайте по порядку
1. Масштабирование бизнеса, открытие доп.магазинов , для магазинов будет по сути тот же интервейс, лишь только с данными своих клиентов ,
вы учли что доп.магазины должны иметь своих менеджеров, что работа с клиентами должна вестись по связке клиент - менеджер - магазин. учли возможность перемещения заказов от точки к другой, (одна тупо закрылась, или расширение точками) , старые заказы остаются на прежней новые создаются на новой, учли видимость заказов/клиентов/платежей/позиций/отгрузок/ и тд точек между ГО, дилерами, магазинами ???
2.Загрузка прайс листов этих магазинов,какие то их акции..
это вообще интересная тема, какие форматы собираетесь поддерживать текстовые ок, а как xls, файлы в архивах ? хватит ресурсов сервера их парсить, в разных кодировках, с постоянно меняющейся разметкой? прайсы. кроссы. номенклатура, замены?
3. Приемка товара с помощью сканера по штрих коду или иное, выдача товара со склада
Складской учет, приходы, отгрузки, импорт , экспорт в разных форматах, сопоставление состояний, складские остатки, резервирование, складские ячейки, хммм. осилите?
4. Отправка заказов поставщику на почту, если поставщик загружен с помощью прайс листа. Ок отправили, поставщик шлет обратно на потчу, автозагрузка? работа с разными почтовыми серверами ? автоприходования. автоппоиск писем с вложениями, сопостовление статусов. дробление, объедиенение
5. Автоматизация с клиент банком ( приход средств от клиентов) расход средств поставщикам.
....
удачи.)

Начинать нужно с составления ТЗ или что-то другое?

вы точно осилите магазин автозапчастей начиная с таких вопросов?

Как правильно соединять данные Классов?

1. Есть бизнес логика, а она говорит что заказ не может существовать без продукта, и без клиента, а это жёсткая связь.
2. Есть подход к разработке DDD а он позволяет писать приложения не имея базы данных, опираясь на бизнес логику, поэтому если вы выдумали данные правила существования объектов, лучше не усложнять, делать как диктует бизнес

Может ли модель работать с массивом _POST и записывать данные в сессию?

да верно,
$userService->add($request);
но если еще в сторону улучшения
$userDTO = DTO/UserRequest::build($request);
$userService->add($userDTO);

Может ли модель работать с массивом _POST и записывать данные в сессию?

это ответ И еще вопрос: кто должен заниматься валидацией данных - модель или контроллер

а тонкий контроллер это :

//UserController::add

try{

$userService->add($_POST);

}
catch(ValidationErrorException){

return new Response("Ошибка валидации");

}

return new Response("Успешно!");

Как правильно вести разработку php приложения в docker?

все ясно получается composer используется для консольного управления сборкой проекта как альтернатива phing,symfony console

Как правильно вести разработку php приложения в docker?

1. чтобы работать с composer нужен пхп вне контейнера, не возникаеют проблемы с версиями пхп?

2. composer install выполняете уже в докере через docker-compose ?

Может ли модель работать с массивом _POST и записывать данные в сессию?

//UserController::add

$user = $userRepository->buildFromArray($_POST);

$userValidation = new UserValidation($user);

if(!$userValidation->isValid()){
throw new ValidationErrorException($userValidation->getErrors());
}

$userRepository->save($user);

PHP ORM для бизнес приложений?

Так понятно они переключились на 3 версию

Codeigniter стоит использовать для серьезного проекта?

на CI намного быстрее однозначно чем Yii и тем более Symfony

Codeigniter стоит использовать для серьезного проекта?

PSR 7 - PSR 16 это вообще хорошая практика

Codeigniter стоит использовать для серьезного проекта?

DI Container не предпочитаю в остальном согласен

Codeigniter стоит использовать для серьезного проекта?

безопасность никак не связана с CI, все что недостаточно из коробки можно подключить через composer. Серьезный проект это понятие относительное, для кого то пару миллионов товаров обыденное дело, для кого то очень серьезно.
DDD это сперва пишем код, затем используем базу и инфраструктуру, основа домен все остальное вторично.
SOLID это прежде всего хорошие практики написания которые обеспечат поддержку кода.

Как автоматически обновлять репазиторий на сервере git?

я бы еще добавил: поиск на тостере

Организуете ли вы DTO для сервисного слоя?

это, попытка отделения кода апи функционала (бизнес логика) от код клинтского (шаблоны,стили, скрипты,контроллеры) чтобы апи использовать в разных реализациях клиента, не спорю возможно это попахивает DDD.

Организуете ли вы DTO для сервисного слоя?

ок если DTO то данные должны быть с учетом вложенных элементов DTO (агрегат), например если отдаем DTO\Order , то он должен содержать DTO\OrderItem, DTO\Client, DTO\Producer
, то есть должен какой то способ собрать DTO объект для ответа, это куча кода по сборке DTO, это лишние запросы к хранилищу.
Опять же если мне нужен просто DTO\Order без вложенных элементов?