Read models naming

[AnrDaemon]

Мне интересно, какие события вы используете у read модели?
Может, мне понравится и я тоже начну так делать?

 

[WMix]

какие события

все которые изменили его состояние или я чтото не понимаю?
>>> дай корзину
1. новая корзина,
2. положили товар
3. положили товар
4. изменили колво
<<< корзина

 

[Adelf]

@WMix, состояние read модели не меняется. оно вообще immutable.

 

[fixxxer]

@WMix, состояние read модели не меняется. оно вообще immutable.

А, да, вот еще в php не хватает конструкции "public readonly". В typescript очень удобно.

Вообще CQRS и всякие flux-redux это практически одно и то же.

 

[AnrDaemon]

Если на то пошло, давайте замахнёмся на Дельфёвые property XX read YYY write ZZZ;

 

[Adelf]

В typescript оно перекочевало из C#
А там много вкусного еще.
int Id{public get; private set;}

Вообще CQRS и всякие flux-redux это практически одно и то же.

Это да

 

[MiksIr]

int Id{public get; private set;}

решается с помощью annotate based development и трейтика

 

[Adelf]

Решается это с помощью приватного свойства и геттера. Просто писанины больше.

Upd: Хотя я похоже не понял сарказма

 

[MiksIr]

Сарказм сарказмом, а поиск по packagis-у дал пачку таких вот трейтов

 

[fixxxer]

В typescript оно перекочевало из C#
А там много вкусного еще.
int Id{public get; private set;}

В тайпскрипте так (ну, почти так) тоже можно. Да и в обычном JS можно, только много букв писать.

 

[AnrDaemon]

У вас работает поиск по packagist? >.< Я вам завидую.

 

[WMix]

@WMix, состояние read модели не меняется. оно вообще immutable.

мне показалось, что ты собирался строить состояние модели по событиям

Ну я думал генерить эвенты передавая туда read модель. Таким образом, она будет создаваться и внутри сущности и из базы.

 

[Adelf]

@WMix, меняется write модель. Она и генерит события. Слушателям же нужна read модель, чтобы получить из нее данные.

 

[WMix]

Ну все правильно: команды валидируют запрос и пишут события, запрос (квери) читает события и генерит по ним read model. Если события в массиве проецировать, точно накуралесишь. -- нужен обьект.
на клиенте (для кого модель сделана) типизация уже своя, да и интересует его вырезка (граф), те. перед тем как отдавать, вероятно придется закастить в массив и обрезать лишнее. Или опять не о том думаю?

 

[grigori]

А я не про BC.
Они в разных слоях, обе модели друг про друга ничего не знают, и семантически и технически у них разные задачи. Даже слово «модель» к ним применима в разных смыслах.
В противном случае в API ты отдаёшь не «продукт», а «карточку продукта».
Когда удивлённый пользователь API спросит почему именно «карточка», то ты ему расскажешь, что это конфликтует с именем domain model.
Да и domain model со временем переименуешь, ведь на самом деле продукт на полках, а это — «КомпьютернаяМодельПродукта».

Думаю, именование, как одна из трех сложных проблем в программировании, заслуживает отдельной темы.
Отдавать в API "продукт" или "карточку продукта" не должно быть связано с классами программы.
КомпьютернаяМодельПродукта может появиться для какой-нибудь стратегии, но не в API.

 

[grigori]

Да, можно сказать, что Read Model - это частный случай DTO. А в чем проблема с этим?

Пытаюсь понять вас. Иногда выходит, что разницы нет. У тебя в понятие "read model" - входит класс модели, который выполняет запрос, или это только сам класс с данными на выходе из модели?

 

[grigori]

Если бы в PHP можно было описать интерфейс ассоциативного массива, как это делается в Typescript для plain JS objects - можно было бы и так, в Typescript я именно так и делаю.

в TypeScript, как и в golang, задача соответствия отфонарных данных интерфейсу решается через duck typing,
и статическая типизация не нужна для проектирования (@Adelf ) потому что пользовательских типов динамическая типизация не касается

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

 

[Вурдалак]

Отдавать в API "продукт" или "карточку продукта" не должно быть связано с классами программы.

Ну так read model — это и есть API, только внутренний.

Пытаюсь понять вас. Иногда выходит, что разницы нет.

Грубо говоря, DTO — это commands, queries и read models (ответ на query). Наверное, сюда в каком-то смысле можно отнести и events, т.к. эти сообщения — тоже часть внутренного API приложения. Просто классы с данными к/от service layer.
DTO — более общий термин, который, менее ценен в дискуссии, как раз в силу своей общности. Ну да, это DTO, то DTO, всё DTO. С таким же успехом можно было всё называть словом «объект», ну а чо.

DTO — это что-то более техническое, на заре появления этих терминов у программистов уже было понимание, что лучше передавать не кучу аргументов и не запрашивать по одному аргументу, а нужно их как-то группировать. Уже потом появилось понимание, что это сообщения и появились более конкретные и удобные термины. Появилось также понимание, что сообщения — это immutable-объекты (если ты поменял сообщение, то ты получил другое сообщение), а DTO чуть ли не у Фаулера в его PoEAA имеет сеттеры в примерах, т.е. это наивное представление о сути этих объектов. Но терминология эволюционировала, поэтому потребности в термине DTO особо больше нет.

У тебя в понятие "read model" - входит класс модели, который выполняет запрос, или это только сам класс с данными на выходе из модели?

Это просто класс с данными. Сервис, выполняющий запрос — это query service, он принимает на вход query, а на выходе — read model.

 

[grigori]

вот так уже понятнее, спасибо за подробное объяснение.
@Adelf в тему RFC по функционалу форума: нужна wiki для составления словаря, для объяснения значений подобного этому.
самые ценные диалоги оказываются недоступными для понимания, и гуглить "read model" бесполезно - там все еще та самая единственная абстрактная статья

 

[fixxxer]

в TypeScript, как и в golang, задача соответствия отфонарных данных интерфейсу решается через duck typing,

В typescript совсем не так же, как в golang, и оба варианта не совсем duck typing, но это уже совсем оффтопик.

__get

Happy refactoring, bitches.

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

Постоянно надо, когда работаешь с коллекциями в том или ином виде. PhpStorm-овская поддержка PhpDoc вида @return Foo[]|Collection, конечно, выручает, но все же это не на том уровне.