Максим

Зачем вам разбираться, как работает сложный бандл. Вам нужно разобраться как это сделать минимальными усилиями. Могу лишь подсказать как это сделать. Потому что описывать как работает бандл долго и ни к чему.

1. Делаете новый роут и в нем проверяете входящие данные. Если это логин и код из смс, то ищете эту связку в базе и если нашлась, то формируете JWT и отдаете frontend приложению.
2. Делаете Аутентификатор, который берет заголовок токена из запроса, извлекает из него токен и проверяет его на различную валидацию: подпись, срок действия и т д

Ну а дальше если есть вопросы можете написать их в комментариях.

Если правильно понял, то вопрос касается ссылок в HTML. Вам нужно ссылку использовать в не относительные. То есть все ссылки должны начинаться с /manage/module/site вместо manage/module/site

Используйте JWT токен, в котором будет ID и роли. По пори проверяйте есть ли доступ администратора. В каждом запросе делать проверку не нужно. Это можно закрыть глобально по роли.

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

В момент, когда платеж был выполнен публикуется интеграционное событие PaymentPaid. В это событие вкладываете все нужные данные, в том числе и ID по которым связываются платежи. Далее сервисы, которые заинтересованы в этих событиях подписываются на них и совершают нужные действия.

При работе с RabbitMQ нужно помнить:

1. Он гарантирует как минимум 1 раз доставить ваше сообщение. Это значит, что вполне может быть дубль и вам нужно быть готовым к этому. То есть делать идемпотентный консьюмер.
   
2. Сообщение может быть не доставлено по причине недоступности сервиса очередей, так же и сообщение может быть потеряно, в том числе из-за недоступности сервиса. Поэтому вам нужно гарантировать доставку через Outbox.
   

Самый лучший способ это Event Storming! Это как раз будет связующее звено для понимания и вами и программистами. Конечно, лучше найти такого специалиста - Архитектора.

По сути техника Event Storming — это воркшоп с простой структурой, на котором эксперты по предметной области и разработчики совместно исследуют эту самую предметную область. По мере исследования участники раскрывают всё больше неопределенности и скрытой сложности, сверяют предположения с реальностью и снижают влияние предположений на качество продукта.

Event Storming применяется в исследованиях клиентского опыта, проектировании новых сервисов, получении знаний о работе legacy-систем, моделировании сложных предметных областей и проектировании микросервисной или событийной архитектуры.

Техника предусматривает итеративность. Модель предметной области можно постепенно детализировать (уточнять) с каждой сессией. Участники меньше утомляются, сессии можно посвящать отдельным вопросам и приглашать нужных специалистов, брать паузы для исследований.

Из своего опыта могу сказать, что ни раз даже помогало увидеть полную картину своего бизнеса. Сразу вырисовывается организационная структура, разграничение ответсвенностей и другое. Проводится довольно быстро. Это легче чем написать ТЗ. После проработки Event Storming можно уже давать задания для программистов, дизайнеров, маркетологов и др. Очень полезная техника для автоматизации. Всегда проще сначала нарисовать бизнес, а потом его автоматизировать.

Если вы автоматизируете уникальный продукт, где есть своё ноу хау, то без этой техники не обойтись. Ведь выбирая что-то за основу и копируя её вы не доносите ценность вашего бизнеса. Для примера, ваша ценность может быть вовсе не в качественных и вкусноприготовленных блюдах, а в грандиозном сервисе подаче этих блюд. Тогда автоматизацию следует делать с большим упором на услуги. Или ваш ресторан наоборот может иметь самый быстрый сервис и подачу блюд. В этом случае упор будет другим. А может быть у вас в целом подход будет заключаться в управлении другими ресторанами (сеть). В общем брать что-то за основу и тем более слушать программистов не стоит. Программисты делают всегда то, как им удобнее и проще. Для вас же важно решить свои проблемы. Удвоить бизнес.

Не очень понимаю в чём вопрос) Том Docker – это каталог (или коллекция файлов), который находится в файловой системе хоста и не является частью UFS контейнера. Именно внутри этих томов контейнеры способны сохранять свои данные. С помощью команды docker volume вы можете легко управлять томами. Соотвественно куда вы прокините том - там и будут жить ваши данные на машине.

Sentry, Elasticsearch+Logstash+Kibana. Больше особо нечего сказать)

Для PHP есть библиотека Monolog, которая умеет легировать в разные источники.

Первая ссылка похоже на правду. Вторая тоже относится к архитектуре, но как-то слабо описано.

В целом архитектура нужна для того, чтобы проект и его код был понятен каждому. Чтобы доработки делались просто. Чтобы одна ошибка не приводила к смерти всего проекта. Другими словами Архитектура ПО (разработка архитектуры ПО), это искусство и наука строить и проектировать программное обеспечение таким образом, чтобы оно удовлетворяло всем заявленным к нему требованиям, а также обеспечивало максимальную простоту доработки, развертывания и масштабирования приложения.

Архитектура и про код, и про технологии, и про инфраструктуру.

1. Нет деления по слоям из DDD. Нужно отделять бизнес логику от инфраструктуры. Ответственно контроллерах минимум кода и никакой логики.
2. Анемичные сущности, которые не имеют контроля над своим состоянием агрегата.
3. Сущности знают про то где они хранятся. Если завтра мы начнем хранить данные в другом месте, то ваш код придётся переписывать.
4. Про структурные паттерны можете почитать тут: https://refactoring.guru/ru/design-patterns/struct.... Там есть примеры на PHP.

В целом могу сказать, что код пишется для человека, а не для машины. Поэтому не нужно бездумно писать код и раскидывать всё в разные папки по всему проекту. Выделяйте модули и ложите всё рядом с ним. Можете почитать про модульный монолит.

Например, у вас Request размазан по разным папкам: Events, Models, Listeners и т д. Вам завтра скажут вынести модуль заявок в отдельный сервис или вообще его удалить. Вместо того чтобы удалить одну папку, то вам нужно во всех папках найти где есть Request. Конечно, это не удобно. Не говоря о том, то вся логика, в том числе и бизнес логика хранится по всему проекту. И это у вас простой код. А что если будет 100 разных модулей. С вашей структурой вы точно увязните. Плюс у вас будет куча конфликтов при разработке. Нельзя за каждым программистом закрепить папку, за которую он отвечает. Каждому программисту придётся лезть в соседнюю попку, потому что они общие. Ревью делать тоже сложно.

У вас вопрос про данные, а не про константы. Где хранить данные зависит от самих данных!

1. Если нужно гарантировать их безопасность (например, персональные данные), то без хранилища не обойтись.
   
2. Если нужно их менять не через код, то тоже нужна веб панель и хранилище.
   
3. Если какие-то данные повторяются, то эти данные можно выносить в какие-то js/json файлы.
   
4. Настройки проекта, зависящие от окружения, выносят в переменные окружения.
   
5. Статические страницы вроде о нас и контакты меняются не часто, поэтому можно оставить их прямо в файлах.
   
6. Требуются ли переводы контента и т д
   

Это лишь часть описанных вариантов. Как бы вынес я, исходя ваших пунктов:
1. Контакты в шапке (телефон, мейл, адрес) - если только там оставить прямо в коде. Если дублируются вынести в отдельный файл и его подключать.
2. Структура меню (Главная О нас Блог и тд — названия пунктов меню и их href-ы) - внутри компонента меню, если нет требований менять из админки и переиспользовать компонент. В противном случае - хранилище или json файл.
3. Текста на страницах О Нас, Как добраться и тд - база данных или прямо html кодом статично.