Dr. Bacon, появился, роадмапу и источники я уже нашел. Но также и появился опыт шаринга знаний. Есть вещи, которые не всегда очевидны для пришлого в новую тему человека.
Adamos, я, вероятно, не вполне корректно описал вопрос. Мысль как раз заключается в том, что в домене Payment создается пакет Factories внутри которого лежат разнообразные фабрики, условно, для сущности Payment. То есть, это фабрики конкретно этого домена. Не фабрики для других доменов, которые используются этим доменом, а именно фабрики только этого домена.
Adamos, то есть, если у нас есть модуль, который выполняет некоторый бизнес-кейс, у него есть 7 сервисов. И, например, 4 связанных с сервисами фабрики, то все эти сущности нужно смешивать в одном пакете?
Приходит сообщение, о регистрации нового пользователя в exchange, например, user.new оттуда сообщение направляется в очередь user.new.queue_one. Существует ряд критически важных бизнес задач, которые нужно выполнить на это событие. Например, отправить уведомление на email, sms-оповещение, добавить данные в базу, обновить некоторые записи.
Все эти действия сейчас выполняются в одном консьюмере. Консьюмер пробегается по списку обработчиков и исполняет задачи.
Вопрос в том, можно ли под каждую такую критически важную задачу создать отдельную очередь и отдельный консьюмер? Зачем? Например по этой причине:
Тут возникает проблема, например, если хендлер не смог выполнить задачу и ее снова нужно послать в очередь, что все успешно выполнившие хендлеры выполнят эту задачу еще раз, что создаст сайд-эффекты.
Соответственно, поскольку переменная не была взята из внешнего лексического окружения -- она уже есть у обычной анонимной функции. У стрелочной же ее нет по определению, поэтому она берет ее из внешнего лексического окружения.
И поскольку заданная функция вызывается внутри setTimeout в нее пробрасывается другое окружение, отчего там нет ожидаемого контекста. Я правильно понимаю?
mayton2019, хорошая мысль. Как раз думал о том, чтобы вынести некий обобщенный функционал по генерации sql в отдельные хелперы и структуры данных. Затем объявить некий базовый интерфейс query-builder и для каждой модели его имплеменировать по-своему, используя эти хелперы.
Условно говоря, развязать себе руки там где это удобно. А рутинные вещи автоматизировать.
Василий Банников, конструктор можно переопределить в потомке, изменить его сигнатуру. Либо вообще не объявлять его у родителя, а объявлять только у потомков.
FanatPHP, ситуация комичная. Пишу проектик для одного человека, впоследствии нужно будет подробно объяснить ему как это работает. Объяснить ему принцип внедрения зависимостей будет сложно.