да все тоже что и обычная модель

рид модель - это просто дабы брать данные как мне нужно, быстро и эффективно а не через орм

где-то тут проскакивало по чату

просто на запросы чтения вида
GET /cars/list?filter....
я буду брать из базы данные не через сущность а чистым скл для скорости

спасибо)

Меня смущает в рид модели её практически неотделимость от доступа к БД.

У меня такой кейс. Есть 2 проекта: один легаси с AR, второй - это переписываемый первый c доктриной. Но переписывается не тупо с фреймворка на фреймворк, а с постепенным выносом бизнес-логики в отдельный core пакет, в котором красивая доменная модель, куча валидации и тестов. core через composer подключается в проект-consumer.

В core - чистая domain model, UseCases для неё и интерфейсы-адаперы. UseCases - это в основном запись, а вся инфраструктура для доступа к базе скрыта за адаптерами. То есть их конкретная реализация пишется уже в проекте-consumere core.

Так вот если с UseCases понятно и все красиво, то с ReadModel не очень понятно. Потому что с одной стороны хочется некоторые Queries вынести в core  и сделать частью core функциональности приложения, с другой стороны, по идее вынести можно только какие-то DTO-объекты, а Fetcher-ы вынести не получится так как они обычно используют базу напрямую (то есть чистый SQL пишется).

Или может я размышляю о несовместимых вещах.. Или может быть рид модель все таки специфична для каждого consumer-проекта и тут это неприменимо.

почти точь  точь как у Eliseev'а))

да там явно пуля в пулю

так рид модель и есть ядро

аналогично с юзкейсами, вы создаете контракт, что вот эта рид модель читает данные из возвращает их в виде такого-то дто
а уж что вы будете делать с этим дто далее - вообще не проблема рид модели
ее задача быстро достать нужные данные с соблюдением контракта

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

ваше ядро должно уметь изменять данные и читать их
а как это делается внутри уже никого не волнует
вот для ядра вы и используете модель на запись, рид модель на чтение потому что быстрее

То есть в этой логике знание о конкретной БД и инфраструктура для доступа к ней являются частью ядра?

да, а ядро выставляет наружу некий апи для доступа

под словом апи не нужно понимать рест :)

хотя опять же, смотря что вы называете ядром, может мы по-разному понимаем

может у вас ядро это чистая бизнес логика

Идея моего ядра была в том, чтобы отвязаться от кучи ларовских недомоделей, и вообщем-то от доктрины и вынести бизнес-логику как раз в отдельное место, никак от инфраструктуры не зависящее.

таким образом можно постепенно это ядро в новой версии использовать сразу и это сводится к подставлению нужных реализаций адаптеров для инфраструктурных сервисов и реализации Presenter слоя в виде какого-то API (контроллеры валидируют входящие данные, дергают нужные юз-кейсы, форматируют вывод). Говоря о данных, по факту просто реализации репозиториев делаются и инжектятся в ядро.

А так как легаси проект не умрет сразу, там тоже рефакторится код на использование ядра, дабы не поддерживать сразу две код-базы.

ясно, я понял это по-другому
тогда мои идеи не применимы к вашей архитектуре

у вас ядро это логика, а данные поступают откуда угодно
тогда я так себе думаю нет ничего плохого в том чтобы эти данные каждый собирал как мог и откуда мог
но это будет сильно распылять знание разных частей об инфраструктуре

может быть вам стоит подумать в сторону чтобы и инфрастуктуру вынести в отдельный проект аля как ядро