Проектирование api

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

Нужно уходить от этого, и дробить это на независимые контексты, независимые сервисы.

Модульное разделение кода

Делим класс Product на подклассы. В них будет информация которая нужна только для этого сервиса

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

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

Товар и пользователь при таком подходе хранится везде, а не в одной таблице.

Как это выглядит в коде

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

• Author
• Blog
• Comment
• Data
• Favorite
• OAuth
• Payment
• Product
• HTTP

В каждом модуле лежит набор директорий с классами, к примеру:

Модуль words работа со словами

   Words
    Entity - сущности
        Word - название сущности
            Word.php - класс сущности
            WordRepository.php - репозиторий сущности
    Command - команды
        Word - название сущности
            CreateWord - название команды
                Command.php - класс команды
                Handler.php - обработчик команды        

Например, класс Command.php. Это просто DTO.

<?php

declare(strict_types=1);

final class Command
{
    public function __construct(
        public string $name = '',
        public string $description = ''
    ) {
    }
}

Здесь самое важное, нужно строить структуру удобную в первую очередь нам!