Здравствуйте. Параметры которые присущи каждому сервису стоит использовать в конструкторе репозитория, например на php это выглядит так:
class OzonEntityRepository impliments EntityRepositoryInterface{
public function __construct(private string $secretKey, private string $idClient)
}
public function userActivation(UserActivationDto $object){
//.........
}
На самом деле есть решение, делали сервис на сайте федерального уровня, 300 точек по всей стране, 400тыщ позиций ежедневного из прайсов поставщиков. Сперва работало на базе сайта, потом поняли что нужно выделить в отдельный сервис , и работу с сайтом организовать по АПИ. Почему отдельный сервис потому что есть процессы который сложно организовать на сайте: очередь, конвертация больших файлов >20мб Excel и другие нюансы. Получилось неплохо.
Написали такой функционал для одного ИМ федерального уровня, загрузка прайсов ежедневно по 300 штук, 400тыщ позиций в день, схема МойСклад (Поставщики) -> Сервис -> ИМ. Потом решили выделить в отдельный сервис, так как появились клиенты требующие аналогичные схемы, например ИМ -> Сервис -> Ozon. Попробуйте может зайдет. Там есть анализ цен конкурентов.
1. Хорошо спроектировать, и держать систему на виду помогает Event Storming + miro
2. На выходе мы имеем команды, события, сущности(агрегаты), информация, контекст
3. В зависимости от приложения элементы с 2 шага преобразуются в код
Когда вы тестируете метод А вашего класса, вы проверяете его логику а не логику других (замоканых методов), может быть ситуация когда ваш метод А работает по логике корректно, а вот другой метод Б другого класса используемый в тестируемом методе выдает ошибку, возникает вопрос нужно ли считать что ваш метода А работает неправильно из за упавшего метода Б ?
человек спрашивает про структуру папок, а ему фрамеворки и cms впаривают)))
я бы порекомендовал каркас пакета https://github.com/php-pds/skeleton
публичный файлы css,js,img и index.php поместить в public/
остальной php код в /src
хорошая практика один проект - один докер конфиг
поэтому проекты на php5.6 и php7.3 будет иметь каждый свою версию
поэтому шаги простые
1. переходишь в папку проекта
2. $ docker-compose up -d && docker-compose exec app bash
3. $ php some_script.php
как мне очень трудозатратно, нужно разделение фронт и бек, или хороший фулстек программист.
как правило если у вас SAAS сервис и требуется клиентоориентированный интерфейс то 90% индивидуальная админка + rest.
если же cms которая теражируется клиентам, должна иметь возможность кастомизироваться то подойдет многостроничник на bootsrap, с twig и фреймворком.
