А вот и актуальный хэйтинг подоспел
Во всех бэках на спринге (со Spring Data Jpa), которые я видел, был репоз на каждую табличку (кроме свяазующей многое-ко-многому).

И не то, а чём думали авторы Spring Data: https://stackoverflow.com/questions/21265262/are-you-supposed-to-have-one-repository-per-table-in-jpa/21277087#21277087

А наткунлся я на это вот этой любопытной ссылке - https://spring.io/blog/2018/09/24/spring-data-jdbc-references-and-aggregates
походу, можно юзать спринг дату для бойлерплейтного кода, но не тащить при этом адовый проект.

а вот в эту ссылку я полез после того, как в своём петпроджекте на кторе и ебине проапгрейдил ктор 1.4.1 -> 1.4.2 (минор казалось бы), и у меня всё поотавливалось т.к. ебин юзает блокирующий jdbc, а ктор весь из себя на корутинах и не блокирующий и походу впилили туда проверку. И чёт я задумался, что мош спринг не так уж и плох:)

#posts@ergonomic_code #whynojpa@ergonomic_code #dd@ergonomic_code #spring_data_jdbc@ergonomic_code

Рад представить вам анонсированный разгромный пост о том почему JPA лучше не использовать в серьёзных проектах:)
Это новый рекордсмен моего блога по объёму - закрыл гештальт:)

Ну и если я вдруг налажал с технической точки зрения - пишите. Может я, наконец, 15 лет спустя открою страшную тайну как правильно готовить JPA:)

#posts@ergonomic_code #whynojpa@ergonomic_code #spring_data_jdbc@ergonomic_code

Привет!

Ещё чуть-чуть хейта хибера :)
Скажите, когда хватит:)

#posts@ergonomic_code #whynojpa@ergonomic_code

Привет!

Ночные мысли.

Хибер и спринговый компонент скан вроде как дожны увеличить продуктивность программиста. С одной стороны.

С другой стороны, по моему опыту, проект на хибере и компонент скане в среднем стартует 30-60 секунд. На моём топовом 12-ядерном i7 19ого года с 32 гигами быстрой оперативы и быстром ссд.

И я никогда не жду эти 30-60 глядя в консоль. В лучшем случае иду чатики проверить. А то и покурить. И хорошо если не в курилку, где легко можно на полчаса залипнуть (когда в офисе работал).

В итоге один рестарт приложения стоит в среднем минут 5.

А спринг и хибер не особо дружат с хот релоадом. Да и я не уверен, что многие девелоперы вообще знают о нём. Но даже с хот релоадом у меня выходит

В общем такой наброс: компонент скан и хибер увеличивают время разработки на 10% только за счёт времени старта (не говоря уж о войне с автомагией и адовыми багами вызванными её не правильным использованием).

Увеличивают ли они продуктивность на столько же? Не уверен.

#ergo_approach@ergonomic_code #whynojpa@ergonomic_code #spring@ergonomic_code

Привет!

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

И одним из аспектов кризиса является разочарование в агрегатах и Spring Data JDBC. Я пока не понимаю где проблема - в самих идее и технологии или ДНК (моём) и у меня нет другой идеи как делать эргономичный персистанс, поэтому пока придерживаюсь старой схемы.

Так вот, накопал интересный доклад о Spring Data JDBC от его разработчика. Он там из первых рук объясняет мотивацию создания модуля (мало кто в мире понимает и может эффективно использовать JPA, за пределами туториалов и хелло воролдов) и даёт пачку рецептов решения не совсем тривиальных проблем.

И этот доклад натолкнул меня на интересную мысль: Агрегаты и неизменяемая модель данных - идеальная комбинация.
По задумке, все изменения в агрегате должны проходить через его корень.
И если у вас модель изменяемая, то для соблюдения этого правила есть только два пути:
1) Полностью инкапсулировать все сущности внутри агрегата. Но в этом случае в агрегате придётся нагенерять гору методов для чтения данных некорневых сущностей.
2) Отрубать руки за прямую мутацию некорневой сущности. В прямом смысле, потому что более мягкое наказание будет приводить к нарушению этого правила, из-за невнимательности или спешки.

Потенциально есть ещё вариант с package private методами для мутации некорневых сущностей, но:
1) В Котлин package private всё ещё не завезли:(
2) Это требует пакетирования по агрегатам
Однако главный аргумент против того, чтобы не искать способ соблюдать это правило в изменяемой модели - императивный код сложен в понимании и подвержен ошибкам

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

#ergo_approach@ergonomic_code #spring_data_jdbc@ergonomic_code #talks@ergonomic_code #whynojpa@ergonomic_code

Привет!

Продолжаю проверять гипотезу, что это у меня проблема в ДНК, а с агрегатами и Spring Data JDBC всё ок, смотрю очередной видос

Всё тот же автор Spring Data JDBC одновременно:
1) пинает JPA
2) восторгается агрегатами
3) предлагает декомпозировать систему на основе агрегатов
4) запрещает циклы в зависимостях
Смотрю как в своё зеркало 21ого года:)

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

Ну и наконец:
"it will feel painfull ... but people have to think where stuff belongs and this alone is I think a great benefit"
Со второй частью согласен полностью. Но хочется найти способ обойтись без боли

#talks@ergonomic_code #spring_data_jdbc@ergonomic_code #whynojpa@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Я посмотрел Migrating from (Spring Data) JPA to Spring Data JDBC.
И пересмотрел Меняем Spring Data JPA на Spring Data JDBC! (на который уже писал своё фи).

Удивительно, насколько эти доклады об одном и том же разные:
1. Дженс начинает с тестов и выделяет для них целый слайд. Андрей между делом упоминает их в конце доклада
2. Дженс топит за то, чтобы делать это очень аккуратно и постепенно и рассказывает про любопытную методику больших рефакторингов. А Андрей шарашит с распахнутым забралом и даже без тестов
3. Дженс практически ~50% доклада (~20 минут из ~40) посвящает перепроектированию модели данных. Андрей посвящает этому ~3% (~2 минуты из ~60)
4. Естественно, Дженс чморит JPA, а Андей - SDJ

Зато, оба доклада раскрывают тему генерации id 🤷‍♂️ И я до сих пор не понимаю, чем default nextval('seq') плох, раз уж generated always as identity не подходит

И эта разница навела меня на новый аргумент против jpa за sdj.

При разработке приложения на базе JPA основными сложностями будут изучить саму JPA, потом накастовать аннотаций, чтобы она делала то, что надо, а через полгода угадывать как это всё будет работать. Это всё - привнесённая сложность (Accidental complexity), которую можно и не привносить.

А при разработке приложения на базе SDJ основной сложностью будет декомпозиция модели на агрегаты. И вот это уже сложность, присущая задаче.

И хотя, теоретически, JPA позволяет так же выполнить декомпозицию модели, она не обязывает это делать.
В результате в приложениях на JPA на декомпозицию предметной области забивают и в ответ получают Big Ball of Mud. Так произошло в 100% проектах на JPA, которые я видел.

Проектирование агрегатов - действительно сложная тема и по ней написано много хороших книг. Но с ними со всеми есть одна проблема - они полагаются на экспертов предметной области.

И хотя это лучший способ выполнить декомпозицию предметной области, у него есть недостатки:
1. Эксперты предметной области зачастую недоступны в принципе.
2. А когда доступны - извлечение формальной модели из головы другого человека средствами естественного (неформализованного) языка - это в целом задача на уровне "мишшн импоссбл", а для многих технических специалистов просто за гранью понимания.

Из-за этого проектирование агрегатов зачастую хромает на обе ноги.

Поэтому я сейчас использую более технический подход к проектированию агрегатов. Об этом подходе надо написать отдельный пост, но если вкратце, он выглядит так:
1. Спроектировать ЕР модель, особое внимание уделить слабым сущностям
1.1 Признаки слабой сущности:
1.1.1 её жизненный цикл ограничен жизненным циклом другой сущности - позиция заказа не может существовать без заказа, номер не может существовать без отеля
1.1.2 она упоминается всегда в контексте другой сущности - вторая строчка заказа такого-то, номер 215 отеля такого-то
2. Все стержневые сущности (со слабыми и без них) считаются корнями агрегатов
3. Провести транзакционный анализ - в идеале в рамках одной транзакции должен меняться один агрегат и меняться целиком. Если это не так - что-то надо объединить, а что-то разделить.

Этот подход базируется на косвенных признаках (жизненный цикл сущностей и UI), поэтому он, скорее всего, даст менее точную модель, чем построение модели вместе с экспертом. Но он не требует эксперта и общения с ним. И лучше так, чем никак.

Ещё ссылки по теме:
1. Нотация описания неизменяемой модели данных (+ Ответы на вопросы по Эргономичной нотации ER-модели)
2. Агрегаты
3. Рациональный подход к декомпозиции систем на модули или микросервисы

В общем, инвестируйте свой интеллект в решение присущей сложности задачи, а не привнесённой:)

#why_sdj@ergonomic_code #whynojpa@ergonomic_code #ddd@ergonomic_code #spring_data_jdbc@ergonomic_code #jpa@ergonomic_code