Read models naming

Adelf

Administrator
Команда форума
Я тут начинаю один side-проект. Решил организовать некий CQRS. Write models - доктриновские сущности без геттеров, с методами-глаголами. Read models - обычные классы.
Если сущность Product, то как назвать read модель с продуктом? Тоже Product? как-то мне это не нравится.
Я чего-то не понимаю? Литература, ссылки?
 

Вурдалак

I'd like to model your domain
Я раньше пытался добавлять суффиксы (-Dto, -ReadModel), но потом понял, что это только мусорит сигнатуры методов, а смысла ноль: я всё равно сущность и read model не могу перепутать.
 

Adelf

Administrator
Команда форума
Ну я думал генерить эвенты передавая туда read модель. Таким образом, она будет создаваться и внутри сущности и из базы. Таким образом единственное место, где будут оба класса - это сам класс сущности. Так, что можно пережить.
А это нормальная мысль? :)
 

Вурдалак

I'd like to model your domain
Это типа $this->record(new ArticleWasApproved($this->id, $this->state))? Это очень плохая мысль.
 

Adelf

Administrator
Команда форума
$this->record(new ArticleWasApproved($this->getReadModel()))

Но вообще, да. Не очень.
Я говорю об эвентах в понимании laravel. Например
ArticleWasApproved =>
ClearArticleCache,
SendArticleInfoToSomeViralityAPI - вот здесь, допустим, нужна рид модель. Доставать ее из id запросом?
 

Вурдалак

I'd like to model your domain
Доставать ее из id запросом?
Да.

$this->record(new ArticleWasApproved($this->getReadModel()))
Это абсурдно хотя бы потому, что сама read model в идеале строится на основе событий модели и необязательно одной. В смысле, там нормально иметь кучу денормализаций, которые как раз не хочется держать в обычной write model. В противном случае возникает вопрос зачем тебе вообще разделение моделей, если у тебя свойства read model замечательно хранятся и вычисляются внутри write model.

Да и read model может быть несколько.
 

fixxxer

К.О.
Партнер клуба
Если ты можешь легко сделать $this->getReadModel(), то нафига вообще read model-то отдельно? Типа, через промежуточный класс геттеры сразу станут норм? :)
 

Adelf

Administrator
Команда форума
Пока нечего показывать. Потом, если стыдно не будет.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
а расскажите для тех, кто в танке, пример когда read model нужна, и чем она отличается от DTO?

Lля меня первый закон проектирования - бритва Оккама, чистые Value Object считаю бессмысленными, если они не предназначены для передачи как DTO.
В сущности может содержаться например, валидация - и это уже не read model.
Интересно увидеть другую логику.
 

fixxxer

К.О.
Партнер клуба
@grigori, если тебе так хочется именно техническое, а не семантическое отличие, я только что придумал специально для тебя: DTO сериализуем, а read model - совершенно не обязательно.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@Вурдалак, темы все те же. Спасибо за ссылку, кто зайдет сюда - откроет и прочтет.

по документу по ссылке, read model "специализируется под клиентские запросы", хороша для кеширования, для "денормализации при изменении, а не при каждом запросе" (С).

Теперь замечание по теме: модель, специализированная для генерации ответов на запросы пользователей, не имеет отношения к модели сущности вроде "Продукт".
Я понимаю read model вроде "Каточка продукта" с данными о производителе и цене.
 

fixxxer

К.О.
Партнер клуба
@grigori, чего далеко за примерами ходить? Возьмем этот форум и откроем список постов в любом разделе. Вон там есть количество комментариев, имя автора, последний комментарий. Вот это и есть read model поста. Дальше коллекция этих read models идет во вьюху и рендерится.

Вот как до всяких фреймворков с активрекордами делали - писали метод, который селектит из базы что надо и возвращает массив (то есть коллекцию) ассоциативных массивов (неявная структура которого и есть read model class).
 

Вурдалак

I'd like to model your domain
Теперь замечание по теме: модель, специализированная для генерации ответов на запросы пользователей, не имеет отношения к модели сущности вроде "Продукт".
Я понимаю read model вроде "Каточка продукта" с данными о производителе и цене.
Разные контексты позволяют называть вещи одинаково.
 
Последнее редактирование:
Сверху