Страница входа и Query-модель

Спасибо!

Спасибо!)

Почему Fetcher из FindIdByCreedintials сам строит запрос в базу данных, а не обращается к UserRepository?

Спасибо!

Спасибо!

Спасибо :)

Дмитрий, добавляйте пожалуйста ссылки на гайды - например, с сайта developer.okta.com и oauth2.thephpleague.com

Добрый вечер, Дмитрий.

Подскажите, пожалуйста, если не использовать docker swarm, можно ли как-то прочитать файлы ключей в контейнере?

Пробовал в docker-compose.yml указать файлы ключей через secrets, но на рабочем сервере не получается прочитать файлы, отказано в доступе.

Права на файлы получаются 0400 и создаются от root.

Я пробовал указать mode в docker-compose.yml, но права на файл не менялись.

secrets:
        - source: db_password
          target: database_password_secret
          mode: 0440

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

Здравствуйте. Столкнулся инфраструктурной проблемой и ридмоделями.

В объектах домена понятно дело нет всей информации для построения ридмодели.

К примеру нет понятия кем создана заявка - человеком/ботом. Кто владелец данной заявки, кто редактор.

Но нужна ли она бизнесу? Наверное нет, чем да. Но для построения рид модели понадобилась данная информация.

Как быть?

Единственное что я сейчас вижу это metadata у бизнес объектов куда я могу складировать дополнительную информацию. Создать какой-то отдельный контекст для этого и хранить всё там. Почему отдельный контекст? Потому что это не доменная модель. Бизнесу это не нужно в его контексте. Поэтому и портить доменную модель инфраструктурной частью приложения не хочется. Тогда где же хранить подобную информацию?

Ещё есть кейс - Owner. Когда есть владелец, чего-то и на основании этого надо предоставлять права на редактировании. Опять же это не бизнес требование, а предоставление доступа на уровне приложения. Соотвественно опять не хочется портить бизнес слой контекста. Тогда где хранить?

Хотелось бы услышать Ваши мысли. Благодарю!

Добрый вечер.

Вопрос по поводу хранения запросов внутри модуля Auth в папке api/src/Auth/Query

Я так понимаю ответственности (функциональность) классов/интерфейсов находящихся внутри папки api/src/Auth должны быть изолированны в рамках этого модуля Auth и не могут напрямую зависеть от классов и данных других модулей (которые наверняка появятся в проекте в ближайшем будущем).

Отсюда вопрос, если появится sql query который будет содержать к примеру джойны (я понимаю что можно обойтись без джойнов и собирать к примеру в контроллере результат из отельных простых queries, но как показывает практика простой join по производительности чаще всего выигрывает) на таблицы других модулей тогда где их хранить? Ведь папка api/src/Auth/Query уже не подходит в этом случае (как и соответствующая папка в внутри другого модуля), так как query будет зависеть в данном случае от таблиц уже разных модулей.

В каком месте вы бы хранили такие queries?

Заранее спасибо за ваше время!

Доброй ночи! А почему страница для авторизации сделана на стороне "бэка"? Мы же могли ее сделать на фронте и подгружать из реакта?