Read models naming

AnrDaemon

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

AnrDaemon

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

Adelf

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

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

MiksIr

miksir@home:~$
Сарказм сарказмом, а поиск по packagis-у дал пачку таких вот трейтов ;)
 

WMix

герр M:)ller
Партнер клуба
@WMix, состояние read модели не меняется. оно вообще immutable.
мне показалось, что ты собирался строить состояние модели по событиям
Ну я думал генерить эвенты передавая туда read модель. Таким образом, она будет создаваться и внутри сущности и из базы.
 

Adelf

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

WMix

герр M:)ller
Партнер клуба
Ну все правильно: команды валидируют запрос и пишут события, запрос (квери) читает события и генерит по ним 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, но это уже совсем оффтопик.

Happy refactoring, bitches.

Дженерики помогают не потерять типизацию, когда коллекция передается в общую функцию с универсальной обработкой данных разных пользовательских типов - а часто ли это надо в userland?
Постоянно надо, когда работаешь с коллекциями в том или ином виде. PhpStorm-овская поддержка PhpDoc вида @return Foo[]|Collection, конечно, выручает, но все же это не на том уровне.
 
Последнее редактирование:
Сверху