topuserman

Нашел готовое решение на маркетплейсе.

И также как можно самому сделать - но какая-то муть.. похоже для старой версии было сделано.

1. Либо сначала разрабатывается спека, а потом пишется API. Это если у вас уже готовое подробное ТЗ есть.
Либо пишется API и параллельно (либо после) документируется. В идеале — первый вариант. Мне приходилось работать только по второму.
2. Это просто документация. Насколько строго вы будете валидировать данные - ваше дело. Тестирование — это тоже ваше дело, и другими программными средствами.
3. Насколько я знаю — нет. Да и не представляю, что вы имеете ввиду. Нажать кнопку и получить готовый продукт? На каком ЯП? На каком фреймворке? Как-то фантастично. Вряд ли. Берете какой-то фрейм и пилите сами.

Swagger — это вообще примитивнейший продукт для документирования API. Все что он делает — читает файл в формате OpenAPI и отображает его содержание в удобном для чтения формате. Ну еще запросы к API умеет выполнять для проверок. И всё.

Ширина сайдбара у вас задана изначально, так что вообще никаких проблем:

Так что ли (не прописывал заполнение данных в suggests)

Мне кажется, что как-то так можно:

почти, примерно как-то так:

/** @param array $args */ 
function render(): string
{
    // Распаковка "виртуального" аргумента (массива) в набор переменных для шаблона
    \extract(\func_get_args()[0] ?? []);

    // Перенаправление stdout в буфер
    \ob_start();
    try {
        require __DIR__ . '/path/to/template.php';
    } catch(\Throwable) {
        // Что-то пошло не так...
    } finally {
        return \ob_get_clean(); 
    }
}

можно хранить всё в одной коллекции:

{
   "type": "полка",
   "size":{
      "width": 45,
      "height": 34
    }
}

{
   "type": "стена",
   "size":{
      "width": 11,
      "height": 500
    },
    "holes": 3
}

так что для хранения "зоопарка" и поиска по нему mongoDB подходит.
если будут связи с другими таблицами, могут быть проблемы, потому что JOIN-ы сделать непросто.

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

Вы бутстрап не используете, просто посмотрите как там сделана модалка. Там очень хорошо сделано. В двух словах
Модалка идёт вместе с оверлеем, то есть класс модал при открытии имеет позишн фиксед, и на весь экран. При этом overflow-y: auto. Это оверлей. А в нем уже лежит сама модалка, и если идёт переполнение контентом то у оверлея появляется скролл. При открытии у боди оверфлоу хидден

В сущность должны передаваться конкретные параметры: $id, $login, а не массив $userData, из которого потребуется извлекать эти данные, проверять их тип и существование. При таком подходе вы можете использовать типизацию и будете уверены в переданных данных.

Вы так же можете создавать сущность разными фабричными методами.

Исключение должно быть в методе get() вашего репозитория. И не путайте методы find() и get():

• find() — возвращает сущность или null.
  
• get() — возвращает сущность или исключение.
  

А БД у вас глобально торчит в виде синглтона? Вы даёте id конструктору пользователя, и этот конструктор сам (!) лезет в БД (какую-то), что-то оттуда подтягивает, бросает исключения в зависимости от внешнего состояния...

У какой-то другой сущности, к примеру у приложения, должен быть фабричный метод get_user. Он по идентификатору достаёт необходимые данные (этот код можно в классовый метод юзера поместить) и создаёт на основе этих данных инстанс юзера, например передавая все основные данные в конструктор.

Вообще-то в монологе есть каналы для этого
https://github.com/Seldaek/monolog/blob/master/doc...
А так же собственно, кастомные хендлеры/процессоры. В коде ты используешь стандартный логгер интерфейс, а что куда писать и слать разруливается кофигурацией монолога через di. А если его нет, то стоит задуматься именно о нём, особенно если в перспективе еще какие-то другие форматы и способы логгирования понадобятся - всё будет разруливаться в едином месте через доп. хендлеры/форматтеры и каналы при конфигурации логгера.

Стратегия = полиморфизм, то есть мы завязаны на некий интерфейс, а какая реализация — нам не важно. Это история про зависимости. Ну например почтальон отдает пенсию бабушкам (любым, какой бабушке именно — зависит от стратегии, КОТОРАЯ НЕ СВЯЗАНА с модификацией конкретной бабушки:)

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

Соответственно это никак не похожие паттерны, один поведенческий, другой структурный... Они применяются всегда в любой этап разработки. Я в самом начале могу сделать декоратор обычной бабушки в виде поющей бабушки, а почтальона или внука в виде стратегии написать потом. А могу наоборот — сначала научить возить бабушек на трамвае (через стратегию), а бабушек с костылями (декоратор) добавить позже...

Кое-где не корректные аналогии, и в аналогии стратегия есть бабушка, но в целом для понимания норм и не критично :)

Если в объекте Order будет зависимость ProductList, то не нарушает SRP, тк этот объект (судя по названию) VO и состояние этого объекта необходимо для работы Order.

Но вызывает вопросы способ работы с ним:

создавать отдельный метод getProductList, в котором будет инициализирован класс

Почему не в конструкторе объекта Order? Или почему не из зависимости извне (DI) вообще получать товары?

class Order
{
     private ProductStorageInterface $products;

     public function __construct(ProductStorageInterface $products) 
     {
           $this->products = $products;
     }
     
     public function refundProduct(Product $product): void
     {
           // логика возврата товара 
           // и соответственно изменение  состава $this->products
     }
}

И товары могут подгрузиться из памяти, БД или АПИ внешней.
Тут заодно и принцип инверсии зависимости

UPD: Не называйте метод getProductList(), это ужасно! Называйте как есть: createProductList() или loadProductList(), ну в зависимости от логики.
get -- слишком общее слово и совсем не говорит о том, что происходит. Если все кругом будет сервисами (service) с методами get, то вам весело будет жить...