topuserman

Если не разбираетесь - не парьтесь и оставьте разметку по умолчанию.
HDD монтируется в /media и спокойно используется любыми приложениями так же, как в виндах диск D, например.
Если какие-то приложения хотят писать исключительно в домашнюю папку (как Стим, например), а вы против - можно сделать их папку симлинком на реальную папку на HDD, никаких проблем.
Выносить /home целиком на HDD глупо - многие программы хранят не только настройки, но и дисковый кэш в домашней папке, и быстрый доступ к нему критичен.

Оборачивать массивы какой нибудь выборки в объекты для передачи куда нибудь в другой слой или сериализации и передачи по сети это совершенно нормально, ничего в этом такого нет. Скажу даже больше, это оборачивание в "обьект" даже называние специальное имеет - DTO (DataTransferObject), паттерн. Но путать DTO и обьекты не стоит, т.к. по факту это структуры данных. В С#, С и каких нибудь еще языках для этого есть даже ключевое слово struct, но в пыхе мы такого не имеем по этому заворачиваем в обьекты.

кстати, как называется этот слой приложения, и в чьей зоне ответственности эта задача

Зависит от вашей архитектуры. Если у вас богатая доменная модельно, то эти методы выборки и создания могут быть прям в модели, если у вас анемичная модель, то существует слой бизнес сервисов в которые выносятся методы работы с вашей бизнес логикой.

Меня смущает множество классов, которые в себе очень редко содержат какую-то бизнес-логику

, судя по этому у вас как раз второе. Однако сама выборка из базы это явно не зона ответственности модели, для этого не плохо бы вынести это всё дело в persistanse слой.

Вот это order_fields поле должно быть объектом. В целом, если хочется удобства, целостности данных и надежности, то неплохо бы вместо ассоциативных массивов использовать обычные объекты, самые простые с обозначенными типами для полей, да хоть с паблик полями, или сделать их readonly.

Возможно, это нормально, так и должно быть ? или как архитектурно правильно решать подобное?

Это нормально. Безликие массивы становятся осмысленными сущностями. Такой код становится проще понимать и поддерживать.

Используемый вами подход называется data transfer object (DTO). Широко распространенная практика. DTO отлично сочетается с иммутабельностью, которая присутствует в ваших классах.

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

В результате, на каком-то уровне приложения, происходит выборка, а дальше создаются все необходимые объекты, и внедряются друг в друга. (кстати, как называется этот слой приложения, и в чьей зоне ответственности эта задача ?)

Называется ORM. Находится в ответственности ORM слоя/фреймворка.

И бывает так, что http-запрос выбрасывает php-ошибку (не exception).

Начиная с PHP 7 ошибки тоже выбрасывают исключения, но не типа Exception, а типа Error. И вы их можете точно так же обрабатывать через try … catch.

Если нужно ловить нужно и ошибки, и исключения, то это можно сделать интерфейс Throwable, от которого наследуются Exception и Error.

Соответственно у вас будет что-то типа

try {
  $response = $http_client->get($request);
  $logger->debug([$request, $response]);
} catch (\Throwable $e) {
  $logger->debug([$request]);
}

Написано же в самом PSR-16:

PSR-6 solves this problem already, but in a rather formal and verbose way for what the most simple use cases need. This simpler approach aims to build a standardized streamlined interface for common cases. It is independent of PSR-6 but has been designed to make compatibility with PSR-6 as straightforward as possible.

Грубо говоря, 16 - это синтаксический сахар к 6.

Официальная дока же вполне нормально объясняет. Если коротко - это общий интерфейс к последовательному набору данных, который позволяет читать, писать и искать в этих данных (как в файле). И все это в едином стиле. Интерфейс такой, типа. Грубо говоря нечто вроде юниксовского подхода "все на свете это файл".

Мне не понятно, где тогда хранится весь ответ клиента, если не в памяти ?

В памяти конечно, но так как это оболочка над данными, то реализация скрыта, условно вы можете считать это файлом, который может активно меняться.

Я значительно переработал этот ответ, поскольку мне самому не нравились некоторые моменты плюс я обратил внимание на конкретные примеры из вопроса.

В первую очередь, не надо путать потоки как принцип, абстракцию, и потоки как конкретную реализацию этого принципа в виде механизма потоков в РНР. При этом даже в этой конкретной реализации есть много нюансов, которые не всегда очевидны. Скажем, врапперы в РНР можно разделить на встроенные и пользовательские. Причем даже встроенные могут значительно отличаться по своей реализации.

Например, когда мы вызываем функцию fopen, то в результате мы получаем ресурс, который в себе содержит дескриптор файла, и далее мы уже можем работать с этим файлом не считывая его полностью в память.
Как я понимаю, через потоки.. но что это за потоки ? где именно про них почитать ? это какие-то механизмы операционной системы ?

Вот даже здесь, поскольку fopen работает поверх абстракции, нельзя говорить о едином подходе.
Если у нас самый простой случай - локальный файл - то РНР оборачивает функции для работы с файлами языка С в свою собственную абстракцию. Но ниже - на уровне этих самых функций языка С - никаких потоков нет. Есть обращение к функциям операционной системы, которые просто позволяют прочитать выбранный кусок файла.
Тут никаких вопросов нет, всё честно - если мы прочитали из файла 5 килобайт - значит потратили ровно 5 килобайт памяти.
Но работаем мы с файлом не считывая его весь в память не потому что поток, а потому что так устроена файловая система. А поток этой возможностью только пользуется.

Если же мы открываем не файл, а URL, то РНР начинает извращаться, пытаясь предоставить те же самые инструменты, какие мы используем для работы с файлами, для доступа к ресурсам совершенно другого типа.
И здесь возможны нюансы. Я не знаю, как реализован HTTP wrapper, но в теории HTTP позволяет чтение произвольного объема данных через заголовок Range:. То есть РНР вполне может читать и из НТТР кусками, а не целиком.

В общем поток - это абстракция. Подход. Интерфейс. Способ работы с массивом информации не забирая её всю в память.
При этом реализация конкретного инструмента, использующего этот подход, может быть совершенно самостоятельной, никак с другими не связанной. Мне кажется, что именно этот момент является для вас камнем преткновения: на техническом уровне это совсем не обязательно одни и те же потоки. Но вполне могут быть.
При этом важно не смешивать сам поток и его получатель (получатель вполне может накапливать всю информацию из потока).

А упомянутый в вопросе PSR-7 вообще никакого отношения к потокам в РНР не имеет. Это совершенно отдельная реализация принципа потоков, которая не имеет отношения к потокам в РНР.

1. принято. Если кто-то станет шикать на вас за это — это их проблемы, а у нас свободные нравы!
2. правильно.

С монтированием – по-разному. Как удобнее. Варианты:

• в проекте папка /docker под ней в подпапке /docker/nginx – конфиги nginx, которые биндятся в контейнер по одному, или всей подпапкой. Удобно, если захочется по-живому редактить конфиги;
  
• в контейнер при его билде, инструкциями в его Dockerfile, копируются файлы из папки;
  
• прилетает уже готовый-собранный образ, из которого поднимается рабочий контейнер, не запариваясь расположением конфигов и какими-то настройками.
  

Логи направляются в Stdout контейнера и хранятся Docker'ом. Посмотреть хвост: docker logs --tail 50 имя_контейнера

В оба. Статику будет раздавать Nginx, а скрипты выполнять PHP-FPM.

Самое главное не высунуть php-fpm порт наружу в интернет что бы никто не запустит на нем какой-нибудь зловред.

Если же порт торчит из докера и прикрыт с наружи файр-волом то занчит вы знаете что делаете и принимаете на себя управление рисками you know exactly what you are doing (and are willing to accept the extreme risk)

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

Есть хуки
https://git-scm.com/book/ru/v2/%D0%9D%D0%B0%D1%81%...

Эту инфу нужно искать в отрыве от языка, это уровень операционной системы.
Один из ответов на SO:
What is Under the Hood in a Stream in Programming?
Upd. Еще есть пересекающаяся тема как http streaming,
я когда-то для себя шпаргалку писала (ссылка)