а в чем противоречие

модель то она под UI и есть

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

две сущности?

или как?

ну где даже критерия не спасет можно делать неймед квери

это уже считай тот же твой любимый чистый sql

да не, мне критерии тоже нравятся

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

тупо слать в json_encode

p.s. я похапэшник, у нас может чуть по другому

хз в итоге на практике вполне хватает фронтэндщикам отдать json под их задачи. Модели я проектирую тоже исходя из задач, которые нужны фронту. ЕСЛИ фронту нужны идиотские json (где-то что то замиксовать, где то выкинуть, а там вообще теги по разному называть... итд) то тут и будет в любом случае геморой

потому что нужен будет маппинг

но и при отказе от орм тоже будет маппинг

один хрен если ты берешься за такую задачу будет геморой

> но и при отказе от орм тоже будет маппинг не не, пожалуй я не так выразился. Я не предлагаю отказываться от ORM и фигачить native query, я предлагаю не мэпить результаты запросов на сущности.

а на что их еще мэппить в случае ORM

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

ну в спринг+хибер мы делали такое, вполне легко решается)

ну в спринг+хибер мы делали такое, вполне легко решается)

штука для эластики ж отдельная была?)

была постгря+оракл

использовался просто нужный конекшн для операции

но там были свои подводные камни спринга, он иногда дурно себя вел

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

транзакцию откроет для одной бд и операцию проведет в другой

ну скажу честно - хз

хз... короч я знаю что для java почти все что надо есть

На тему event sourcing. Вот какой самый топовый вариант хранить и ивенты и вообще с ними работать?

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

А если вне сущности, то ещё хуже (

На тему event sourcing. Вот какой самый топовый вариант хранить и ивенты и вообще с ними работать?

немного не понял

кого противно доставать? события?

А чего Егора Бугаенко не позвали?

кого противно доставать? события?

Да

хз но я подпер стикеры с java богами

Да

я просто не понял о чем ты? Я ж не призываю отказыаться от сущностей, ты в случае с тем же event sourcing выборки для UI будешь делать только из read model, нет?

я просто не понял о чем ты? Я ж не призываю отказыаться от сущностей, ты в случае с тем же event sourcing выборки для UI будешь делать только из read model, нет?

Да

Вопрос только по write model и events

вопрос в воспроизведении событий?

И сохранении

ну с сохранением можно тупо сохранять доменные события

И вообще, что аггрегат должен делать

блин надо бы пописать чего

он должен менять свой стэйт + генерить ивенты

по идее

он должен менять свой стэйт + генерить ивенты

Ну это побочное

Самое главное - логика))

Ну это побочное

не ну да)

короч надо пилить наш недо магазинчик

не ну да)

Оно слегка раздражает

через пару часиков засяду

Welcome )

спасибо)

@Enleur

там чего вчера придумали?

надо еще корзину через ES запилить

надо еще корзину через ES запилить

Прям как Грег Янг описывает в докладе?)

Прям как Грег Янг описывает в докладе?)

ну идеальный же кейс для ES)

помимо микро трейдинга

Финансы мне кажется покруче

А ещё есть подозрение, что медицина)

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

Не спорю

тогда возможность проигрывать уже собранные ивенты на новом алгоритме просто бесценна

можно получать довольно точный фидбэк

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

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

в смысле?

Менять ивенты в миграциях - боль

ну не меняй)

Так отсюда и вытекает маленький нюанс)

храни всю имеющуюся инфу, в этом же суть

Очень часто бывает, что вон то старое событие на самом деле 5 отдельных. Поддерживать все версии со временем станет трудно

Не часто, просто бывает

Вот про что я

ну это возможно... возвращаемся к принципам SOLID и хрустальному шару

короч надо пилить наш недо магазинчик

надо требования в readme собрать что ли

надо требования в readme собрать что ли

В gherkin ;))

да, в gherkin было бы идеально) поможешь?)

ну хотя бы ревью