Всем привет.
Подскажите решение довольно непростой задачи.

У меня есть монолит на 3.2, хочу перевести его на 5.1. Монолит состоит из 100+ связных между собой бандлов и все в 1 гит репозитории.

Я распиливаю проект, и связываю подпроекты между собой через композер

 "autoload": {
        "psr-4": {
            "": "src/",
            "tests\\": "tests/",
            "AppBundle\\": "../AppBundle/src"
        },
    },

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

НО!
Возникли проблемы
1 - шторм тупо не видит пространства имен подключаемых бандлов через композер
2 - сервисы все таки ссылаются друг на друга и видимо придется делать 2 вида сервисов, паблик для подключения другими бандлами и интернал, чтобы использовать только внутри бандла.
3 - все сервисы приходится объявлять в стилистике 3.2, т.к. кода нереально дохера.

Подскажите умные мысли на этот счет, если есть.

Спасибо

Я сам задавался этим вопросом прмиерно в другом направлении:
Как я могу знать, что добавление картинки в статью - валидно, ведь у меня отдельно - сохранение картинки в ФС, отдельно создании сущности картинки и отдельно добавление картинки в сущность статьи. Я спокойно могу создать просто сущность картинки и сохранить в  статье. Но ведь  можно сервис картинок передавать прямо в сущность статьи и туда же аплоад файл или еще как.  Но по большому счету, кроме потери чистых сущностей я не получаю профита. Что за кейс "я могу", тут и логики нет -  где можно развалить консистентость.

Но ведь  можно сервис картинок передавать прямо в сущность статьи
ну, насколько я знаю в сущность нельзя никакие сервисы инжектить

1) Пространства имен в шторме можно настраивать в директориях проекта.

Спасибо. Можете поподробнее? Что-то никак не найду.

я имею ввиду из соображений дизайна класса

Возвращаясь к вчерашнему вопросу про валидацию. Вот вам кейс:
Нам в службу приходит валидное DTO, мы собираемся создать какую-то сущность. Сущность в коструктор требует VO.
Для создание VO нам требуется выполнить ряд операций:
- бесплатные по времени: строка должна быть email, либо сравнение с какими-либо константами и т.д.
- Малозатратная по ресурсам: какой-нибудь запрос в базу, например на уникальность email
- Сильно затратная по ресурсам: VO в конструкторе требует данные из какого-то АПИ

Итого у нас есть сущность, у насть есть DTO с данными (контракт данных соблюден), у нас есть n VO из которых мы хотим собрать нашу сущность, но так же мы не хотим при этом затрачивать много времени/ресурсов.

Как сделать так, чтобы сначала были провалидированы бесплатные правила, потом малозатратные, потом сильно затратные
Уместно ли делать в таком случае сложный билдер, который будет полностью контролировать процесс создания сущности?
Например вначале инвокать все бесплатные проверки, затем малозатратные проверки, затем сильно затратные, затем собирать VO и совать их  в сущность?

При этом подходе (с приоритизацией) появляются проблемы т.к. VO больше не отвечает за свою валидность в момент создания.
Например:
1. валидируем уникальность email до создания VO (потому что не хотим вызывать АПИ если email не уникален, при этом данные из АПИ нужны при создании VO)
2. в стат конструкторе VO мы все равно должны проверить email на уникальность, т.к. конструктор могут инвокнуть откуда угодно

^ Это тоже можно решить за счет создания определенных приватных полей-флагов в рамках самой VO. Мол если валидация такого-то поля была инвокнута уже, то повторно валидировать его не надо, либо хранить как-то в кеше

Ваши мыли по этому поводу @dexplon @fes0r

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

Есть такое достаточно простое правило - конструкторам не желательно кидать исключения. Потому тебе нужны фабрики и билдеры. Причем другие сущности вполне могут быть этими фабриками или билдерами. Не надо зацикливаться что фабрика это "сервис с суфиксом Factory"

@vixtrime вот интеерсный подход, оверхэдный, но все же https://stackoverflow.com/questions/25515452/sf2-using-a-service-inside-an-entity/25533968#25533968

сущности типа People или Person обычно быстро ломают SRP и становятся мега жирными и хрупкими. Лучше искать более мелкие агрегаты. Ну или если не хочется то "всеравно у меня за инварианты база отвечает" - в этом случае просто забей на все это и делай как можно проще (вообще это всегда хорошая идея если у тебя там нет колаборации в процессах)

За сервисы типа PeopleManager надо увольнять

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

Есть такое достаточно простое правило - конструкторам не желательно кидать исключения. Потому тебе нужны фабрики и билдеры. Причем другие сущности вполне могут быть этими фабриками или билдерами. Не надо зацикливаться что фабрика это "сервис с суфиксом Factory"

А почему конструкторы не должны исключения кидать?  Как тогда быть уверенным в валидности сущности/VO?

Корень настроек - Directories

на счет fail constrain, суть в том, чтобы проверить сначала малозатратные правила, например уникальность email, а поотом если оно валидно - дерагать какие-то затратные АПИ, например платные АПИ или ресурсоемкие запросы

я имею ввиду из соображений дизайна класса

что бы флоу данных более явный был, что бы меньше сайд эффектов.

Есть много кейсов когда "что валидно а что нет" решает юзкейс по которому ты что-то создаешь. Перетаскивание этой логики в сущность обычно делает все существенно сложнее.

Сущность должна тебе гарантировать что дернув ее метод (а конструктор это ДО этого) изменения стэйта будут консистентны, но за начало жизненного цикла может отвечать кто-то другой

Но ведь  можно сервис картинок передавать прямо в сущность статьи
ну, насколько я знаю в сущность нельзя никакие сервисы инжектить

где в аббривиатуре "ООП" ты нашел "классы" ;)