1. быстрее будет работать, 2. Меньше магии 3. проще в поддержке

тут уже начинаются namedQuery и по сути тот же SQL, что отстойно... поэтому мне нравится пока criteria

http://projects.spring.io/spring-data-rest/

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

мне вот эта концепция нравится, если применительно к java

тупо строишь read модель поверх твоего приложения под те UI которые нужны и не паришься

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

если доводить до крайности - event sourcing

ну я также и делаю с гибером

тупо строишь read модель поверх твоего приложения под те UI которые нужны и не паришься

ну я также и делаю с гибером

но ты же сказал что будешь сущности пхать во вью а то json сгенерит

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

модель то она под 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 было бы идеально) поможешь?)

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

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

Да, вполне)

Тут @yegor256 вещает о java и oop https://youtu.be/qAxLtSYN0nw

о, live

А запись будет?