Привет!
Ночные мысли.
Хибер и спринговый компонент скан вроде как дожны увеличить продуктивность программиста. С одной стороны.
С другой стороны, по моему опыту, проект на хибере и компонент скане в среднем стартует 30-60 секунд. На моём топовом 12-ядерном i7 19ого года с 32 гигами быстрой оперативы и быстром ссд.
И я никогда не жду эти 30-60 глядя в консоль. В лучшем случае иду чатики проверить. А то и покурить. И хорошо если не в курилку, где легко можно на полчаса залипнуть (когда в офисе работал).
В итоге один рестарт приложения стоит в среднем минут 5.
А спринг и хибер не особо дружат с хот релоадом. Да и я не уверен, что многие девелоперы вообще знают о нём. Но даже с хот релоадом у меня выходит
В общем такой наброс: компонент скан и хибер увеличивают время разработки на 10% только за счёт времени старта (не говоря уж о войне с автомагией и адовыми багами вызванными её не правильным использованием).
Увеличивают ли они продуктивность на столько же? Не уверен.
#ergo_approach@ergonomic_code #whynojpa@ergonomic_code #spring@ergonomic_code
Ночные мысли.
Хибер и спринговый компонент скан вроде как дожны увеличить продуктивность программиста. С одной стороны.
С другой стороны, по моему опыту, проект на хибере и компонент скане в среднем стартует 30-60 секунд. На моём топовом 12-ядерном i7 19ого года с 32 гигами быстрой оперативы и быстром ссд.
И я никогда не жду эти 30-60 глядя в консоль. В лучшем случае иду чатики проверить. А то и покурить. И хорошо если не в курилку, где легко можно на полчаса залипнуть (когда в офисе работал).
В итоге один рестарт приложения стоит в среднем минут 5.
А спринг и хибер не особо дружат с хот релоадом. Да и я не уверен, что многие девелоперы вообще знают о нём. Но даже с хот релоадом у меня выходит
В общем такой наброс: компонент скан и хибер увеличивают время разработки на 10% только за счёт времени старта (не говоря уж о войне с автомагией и адовыми багами вызванными её не правильным использованием).
Увеличивают ли они продуктивность на столько же? Не уверен.
#ergo_approach@ergonomic_code #whynojpa@ergonomic_code #spring@ergonomic_code
Прикольный тред (не сильно длинный, минут 5-10) о происхождении термина boilerplate. И, внезапно, это однокоренное слово с "Бойлер"
#posts@ergonomic_code
#posts@ergonomic_code
Twitter
Hillel
Why do we have "boilerplate code"? Where does the name come from? So the Industrial Revolution needed lots of steam engines, which needed lots of steam, which needed lots of water boilers. And the technical challenges of boilermaking pushed contemporary metallurgy…
Привет!
Утренние мысли.
В рамках концепции
> В общем буду теперь двигать эргономичный подход в сторону баланса между удобством навигации/рефакторинга/типобезопасностью и количеством кода, который надо навигировать/рефакторить/использовать.
решил попробовать чутка сдать позиции, и пустить spring data jdbc в слой домена, и спринг в целом в слой приложения/юз кейсов/интеракторов. На этом фоне, внезапно подумал, что надо поглядедь на код анкл Боба - может всё-таки без этого можно обойтись и всё придумано до нас.
А там - ни одной информационной системы. Есть Fitnesse, которая судя по всему с БД вообще не работает. Есть пачка всяких игр и симуляторов, всякая мелочёвка и всё.
Тогда я решил залезть в репоз 8th light (которы вроде бы связанной с анкл Бобом). Там тоже всякая мелочёвка.
Дальше я пошёл просто шукать по гитхабу Clean Architecture. Тут уже появились демо проектики с одной сущностью. Но всё ещё ни одного реального репоза с проектом хотя бы на 5-10 сущностей.
Писать посты и рисовать красивые картинки легко - сам так делаю:) Но “Talk is cheap. Show me the code.” (c) Torvalds.
Знаете хоть один живой пример проекта с чистой архитектурой?
При том, что мне концептуально нравиться идея чистой архитектуры, мне надо учить людей писать реальный код за конкурентноспособную цену, а не демо проектики или шедевры дизайна.
Пойду дальше искать своего Грааля:)
#ergo_approach@ergonomic_code #ergo_persistance@ergonomic_code #clean_architecture@ergonomic_code #posts@ergonomic_code
Утренние мысли.
В рамках концепции
> В общем буду теперь двигать эргономичный подход в сторону баланса между удобством навигации/рефакторинга/типобезопасностью и количеством кода, который надо навигировать/рефакторить/использовать.
решил попробовать чутка сдать позиции, и пустить spring data jdbc в слой домена, и спринг в целом в слой приложения/юз кейсов/интеракторов. На этом фоне, внезапно подумал, что надо поглядедь на код анкл Боба - может всё-таки без этого можно обойтись и всё придумано до нас.
А там - ни одной информационной системы. Есть Fitnesse, которая судя по всему с БД вообще не работает. Есть пачка всяких игр и симуляторов, всякая мелочёвка и всё.
Тогда я решил залезть в репоз 8th light (которы вроде бы связанной с анкл Бобом). Там тоже всякая мелочёвка.
Дальше я пошёл просто шукать по гитхабу Clean Architecture. Тут уже появились демо проектики с одной сущностью. Но всё ещё ни одного реального репоза с проектом хотя бы на 5-10 сущностей.
Писать посты и рисовать красивые картинки легко - сам так делаю:) Но “Talk is cheap. Show me the code.” (c) Torvalds.
Знаете хоть один живой пример проекта с чистой архитектурой?
При том, что мне концептуально нравиться идея чистой архитектуры, мне надо учить людей писать реальный код за конкурентноспособную цену, а не демо проектики или шедевры дизайна.
Пойду дальше искать своего Грааля:)
#ergo_approach@ergonomic_code #ergo_persistance@ergonomic_code #clean_architecture@ergonomic_code #posts@ergonomic_code
GitHub
unclebob - Overview
Uncle Bob. Author of Clean Code. unclebob has 65 repositories available. Follow their code on GitHub.
Привет!
Линкопост
What Modules Are About
Вообще статья о Jigsaw модулях, но там есть пара нужных мне цитат:
> A Java module is a set of packages that declares which of them form an API accessible to other modules and which are internal and encapsulated — similar to how a class defines the visibility of its members.
> If you’re a team lead or an architect of a big new project, or just hope that your software will grow big and/or popular someday, you might well reap great dividends from modules for little effort.
> Over time, the application’s components become entangled, making evolution painful as any change anywhere can affect pretty much anything else.
И тут мы приходим к топику пакетирования, и его самого распостранённого вида - по типу кода (controllers, services, models и т.п.). Ну и заодно к слоёной "архитектуре".
По моему опыту, при таком подходе к "архитектуре" в проектах инкапсуляция отсутсвует как класс. Все классы вынуждены быть публичными и даже просто логически попадают в интерфейс "модуля". И инкапсулировать становится просто не чего. Особенно если разработчик мыслит ~5 категориями - кнотроллер, сервис, модель, репоз, ДТО, исключение. В итоге получаем "application’s components become entangled, making evolution painful as any change anywhere can affect pretty much anything else".
А когда генерят заголовчные интерфейсы, для них *Impl реализации, а потом скалдывают их в пакет .impl и делают всё паблик - это не инкапсуляция. Это карго культ.
Как делать по другому? Я работаю над этим вопросом:) Кажется, медленно, буквально по капли, но верно, но я нахожу ответ на него. Так что, стей тюнед:)
#posts@ergonomic_code
Линкопост
What Modules Are About
Вообще статья о Jigsaw модулях, но там есть пара нужных мне цитат:
> A Java module is a set of packages that declares which of them form an API accessible to other modules and which are internal and encapsulated — similar to how a class defines the visibility of its members.
> If you’re a team lead or an architect of a big new project, or just hope that your software will grow big and/or popular someday, you might well reap great dividends from modules for little effort.
> Over time, the application’s components become entangled, making evolution painful as any change anywhere can affect pretty much anything else.
И тут мы приходим к топику пакетирования, и его самого распостранённого вида - по типу кода (controllers, services, models и т.п.). Ну и заодно к слоёной "архитектуре".
По моему опыту, при таком подходе к "архитектуре" в проектах инкапсуляция отсутсвует как класс. Все классы вынуждены быть публичными и даже просто логически попадают в интерфейс "модуля". И инкапсулировать становится просто не чего. Особенно если разработчик мыслит ~5 категориями - кнотроллер, сервис, модель, репоз, ДТО, исключение. В итоге получаем "application’s components become entangled, making evolution painful as any change anywhere can affect pretty much anything else".
А когда генерят заголовчные интерфейсы, для них *Impl реализации, а потом скалдывают их в пакет .impl и делают всё паблик - это не инкапсуляция. Это карго культ.
Как делать по другому? Я работаю над этим вопросом:) Кажется, медленно, буквально по капли, но верно, но я нахожу ответ на него. Так что, стей тюнед:)
#posts@ergonomic_code
inside.java
What Modules Are About
When the subject of Java modules comes up in online discussions every so often, I get the sense that many people misunderstand what it is that modules are supposed to do. That's understandable, as the name 'modules' does not evoke the precise purpos…
Привет!
У меня тут чудесным образом наложились релизы двух проектов, в одном из которых работаю руками поэтому до октября будут ток линко-посты.
И сегодня у нас Simplicity enables an evolutionary software architecture.
Избранные цитаты:
1) Для того чтобы держать дизайн простым и изменяемым, он должен отражать ментальную модель пользователя (примечание переводчика: а не технические аспекты реализации)
2) Мы ограничены в количестве вещей, которые можем одновременно держать в голове. Изменять ПО сложно потому что, необходимо понимать все последствия изменений, для того чтобы не внести регрессий. Поэтому мы разбиваем ПО на модули. Работая внутри [хорошо спроектированного модуля] в голове надо держать только сам модуль, интерфейсы модулей с которыми взаимодействуем и контракт самого модуля
3) Совет 1: добавляйте новую функциональность добавлением нового кода. Только новая функциональность знает о существующем коде, с которым ей надо взаимодействовать. [Но не наоборот]
4) Совет 2: Если новая функциональность не может быть добавлена только новым кодом, минимизируйте изменения в старом коде
5) Есть прикольная картинка со списком архитектурных аспектах, о которых стоит задуматься при старте проекта
6) Есть прикольная картинка с тем как выбираться из ямы техдолга, когда на саппорт и баг фикс уходит всё время. Там среди прочего есть любопытная идея политики 0 багов - баги чинятся или сразу или не чинятся вообще.
#posts@ergonomic_code
У меня тут чудесным образом наложились релизы двух проектов, в одном из которых работаю руками поэтому до октября будут ток линко-посты.
И сегодня у нас Simplicity enables an evolutionary software architecture.
Избранные цитаты:
1) Для того чтобы держать дизайн простым и изменяемым, он должен отражать ментальную модель пользователя (примечание переводчика: а не технические аспекты реализации)
2) Мы ограничены в количестве вещей, которые можем одновременно держать в голове. Изменять ПО сложно потому что, необходимо понимать все последствия изменений, для того чтобы не внести регрессий. Поэтому мы разбиваем ПО на модули. Работая внутри [хорошо спроектированного модуля] в голове надо держать только сам модуль, интерфейсы модулей с которыми взаимодействуем и контракт самого модуля
3) Совет 1: добавляйте новую функциональность добавлением нового кода. Только новая функциональность знает о существующем коде, с которым ей надо взаимодействовать. [Но не наоборот]
4) Совет 2: Если новая функциональность не может быть добавлена только новым кодом, минимизируйте изменения в старом коде
5) Есть прикольная картинка со списком архитектурных аспектах, о которых стоит задуматься при старте проекта
6) Есть прикольная картинка с тем как выбираться из ямы техдолга, когда на саппорт и баг фикс уходит всё время. Там среди прочего есть любопытная идея политики 0 багов - баги чинятся или сразу или не чинятся вообще.
#posts@ergonomic_code
Привет!
Всегда запускал БД в тестконтейнере один раз на запуск тестов и чувствовал себя при этом плохишом.
А тут выяснилось, что это идиоматичный способ работы с тестконтейнерами. Стабильность тестов при этом не увеличилась, конечно, зато чувствую себя теперь пионером:) Тем который всем пример:)
#posts@ergonomic_code #ergo_testing@ergonomic_code #integration_tests@ergonomic_code
Всегда запускал БД в тестконтейнере один раз на запуск тестов и чувствовал себя при этом плохишом.
А тут выяснилось, что это идиоматичный способ работы с тестконтейнерами. Стабильность тестов при этом не увеличилась, конечно, зато чувствую себя теперь пионером:) Тем который всем пример:)
#posts@ergonomic_code #ergo_testing@ergonomic_code #integration_tests@ergonomic_code
Twitter
Sergei Egorov
@osi @testcontainers I guess we should do better at educating our users how to integrate @testcontainers, as we never advocate for "DB per test" and instead recommend "DB per test session" or even reusable containers, but some third-party articles demonstrate…
Привет!
Большая и довольно хардкорная статья о структурном конкурентном программировании (как вариант - корутины Котлина) и что оно даёт.
ТЛ ДР: примерно то же, что и структурное последовательное программирование:)
#posts@ergonomic_code
Большая и довольно хардкорная статья о структурном конкурентном программировании (как вариант - корутины Котлина) и что оно даёт.
ТЛ ДР: примерно то же, что и структурное последовательное программирование:)
#posts@ergonomic_code
vorpus.org
Notes on structured concurrency, or: Go statement considered harmful — njs blog
Привет!
Скреативил пост в формате "ночные мысли вслух". Вообще ему место здесь, в канале, но там куча картинок, поэтому опубликовал на сайте.
И как-то так вышло, что я случайно изложил в нём всю суть Эргономичного подхода:)
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach
Скреативил пост в формате "ночные мысли вслух". Вообще ему место здесь, в канале, но там куча картинок, поэтому опубликовал на сайте.
И как-то так вышло, что я случайно изложил в нём всю суть Эргономичного подхода:)
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach
Алексей Жидков
Архитектура ориентированная на трансформацию - Алексей Жидков
https://azhidkov.pro/
Привет!
В Applying UML and Patterns вычитал третью интерператцию OCP:
> In the context of OCP, the phrase "closed with respect to X" means that clients are not affected if X changes. For example, "the class is closed with respect to instance field definitions" through the mechanism of data encapsulation with private fields and public accessing methods. At the same time, they are open to modifying the definitions of the private data, because outside clients are not directly coupled to the private data.
Тут под OCP понимается инкапсуляция чего-либо за интерфейсом - т.е. возможность изменить это без изменения клиентов.
Первая интерпретация, у Мейера - язык программирования должен обеспечивать возможность инкапсуляции.
Вторая интерпретация у Мартина - части поведения модуля должны инжектиться, чтобы можно было изменять поведение модуля, без изменения самого модуля.
Кому верить - вопрос на миллион. Наврное всё-таки Мартину, т.к. в этом случае больше вероятность того, что вас правильно поймут.
#books@ergonomic_code #solid@ergonomic_code
В Applying UML and Patterns вычитал третью интерператцию OCP:
> In the context of OCP, the phrase "closed with respect to X" means that clients are not affected if X changes. For example, "the class is closed with respect to instance field definitions" through the mechanism of data encapsulation with private fields and public accessing methods. At the same time, they are open to modifying the definitions of the private data, because outside clients are not directly coupled to the private data.
Тут под OCP понимается инкапсуляция чего-либо за интерфейсом - т.е. возможность изменить это без изменения клиентов.
Первая интерпретация, у Мейера - язык программирования должен обеспечивать возможность инкапсуляции.
Вторая интерпретация у Мартина - части поведения модуля должны инжектиться, чтобы можно было изменять поведение модуля, без изменения самого модуля.
Кому верить - вопрос на миллион. Наврное всё-таки Мартину, т.к. в этом случае больше вероятность того, что вас правильно поймут.
#books@ergonomic_code #solid@ergonomic_code
Хм, я тут понял, нас (разработчиков) сложно найти (рынок перегрет), легко потерять (рынок перегрет) и невозможно забыть (как минимум - в гите записи останутся, а то и набор костылей, подпорок и багов:) )
В Кольцовской поликлинике тетенька, которая принимает документы на прививку, сидит на Gnome 2:) хз какой дистрибутив, поди астра какая-нибудь
πfs - файловая система, которая "хранит данные в числе пи":)
GitHub
GitHub - philipl/pifs: πfs - the data-free filesystem!
πfs - the data-free filesystem! Contribute to philipl/pifs development by creating an account on GitHub.
Привет!
Выжимка из выжимки о тестировании:)
1) избегайте моков любой ценой. в оригинале - "используйте их только на границах модулей". Моя версия - используйте их только для систем вне вашего контроля (внешине сервисы)
2) Избегайте деталей реализации, тестируйте поведение - изменение состояние заметное внешнему наблюдателю
3) Триггером нового теста является не новый метод или класс, а новое требование. Или старый баг - прим. пер.
4) Пишите тесты, которые проверяют юз кейсы или юзер стори
5) изолировать надо не тестирумый класс, от остального кода, а сами тесты друг от друга
Там есть ещё пара пунктов о том, что надо мокать БД и дёргать код напрямую, а не через HTTP. Но тут я не согласен - такие тесты лично мне не дают уверености, что всё работает
#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code
Выжимка из выжимки о тестировании:)
1) избегайте моков любой ценой. в оригинале - "используйте их только на границах модулей". Моя версия - используйте их только для систем вне вашего контроля (внешине сервисы)
2) Избегайте деталей реализации, тестируйте поведение - изменение состояние заметное внешнему наблюдателю
3) Триггером нового теста является не новый метод или класс, а новое требование. Или старый баг - прим. пер.
4) Пишите тесты, которые проверяют юз кейсы или юзер стори
5) изолировать надо не тестирумый класс, от остального кода, а сами тесты друг от друга
Там есть ещё пара пунктов о том, что надо мокать БД и дёргать код напрямую, а не через HTTP. Но тут я не согласен - такие тесты лично мне не дают уверености, что всё работает
#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code
@hgraca
Distillation of “TDD, Where Did It All Go Wrong”
Distillation of “TDD, Where Did It All Go Wrong” Not long ago, UncleBob promoted the conference talk “DevTernity 2017: Ian Cooper – TDD, Where Did It All Go Wrong”. I&…
Говорят ФБ прилёг
Ещё говорят, что сотрудники ФБ не могут войти в здание чтобы починить ФБ, потому что у них электронные ключи, которые не работают без ФБ
Вот почему нам нужны децентрализованные сервисы
Т - технологии
Д - дилемма
https://twitter.com/leahmcelrath/status/1445100877933694976?s=20
Ещё говорят, что сотрудники ФБ не могут войти в здание чтобы починить ФБ, потому что у них электронные ключи, которые не работают без ФБ
Вот почему нам нужны децентрализованные сервисы
Т - технологии
Д - дилемма
https://twitter.com/leahmcelrath/status/1445100877933694976?s=20
Twitter
Leah McElrath 🏳️🌈
Facebook employees can’t enter the headquarters because their badges don’t work, and those already inside can’t enter various rooms because access is linked through the IoT (Internet of Things) and so goes through the same DNS routes that no longer exist:…
Дочитал хроники архитектуры и мне есть много чего сказать по ней.
Во-первых, посты 1-16 содержат сеньерский минимум на мой взгляд. Если человек называет себя сеньером, техлидом или архитектором, но не знает чего-то из этого - у меня появятся большие вопросы к его любознательности, и как следствие квалификации.
Во-вторых, посты 17-19 содержат неплохой вариант предельно гибкой (а значит дорогой) архитектуры. Я с этими постами согласен процентов на 60-80 и уж точно лучше так, чем ни как - будет всё равно удобнее и дешевеле, чем Big Ball of Mud. Но, я бы их сильно сдобрил ФП и на мой взгляд сейчас для индустрии намного актуальнее вопрос того, как делать хорошие приложения, чем как делать гибкие во все стороны приложения.
Наконец, заключение серии навело меня на умную мысль.
Там мужик, в след за Эвансом и Мартином пишет, что именно ядро (бизнес-логика, юз кейсы, бизнес-правила) отличает систему от конкурентов. В целом, по большому счету, я согласен. Но как обычно есть но.
Допустим, все конкуренты используют условный Spring Data JPA. А мы, допустим, используем условный Spring Data JDBC и благодаря этому, допустим, наш продукт:
1) В целом быстрее для пользователей
2) Требует меньше ресурсов железа
3) Содержит меньше багов
4) Быстрее получает новые фичи
5) Благодаря пп 2-4, дешевле
Это всё разве не будет отличительным фактором (и конкурентным преимуществом)? Мне кажется будет.
В общем серию рекомендую к прочтению - она несёт больше пользы, чем вреда.
Я же, тем временем, тоже не катал вату. Я наконец определил содержание книги и написал черновик тизера первой части книги. Уже совсем скоро, я наконец опубликую кусок авторского контента.
#posts@ergonomic_code
Во-первых, посты 1-16 содержат сеньерский минимум на мой взгляд. Если человек называет себя сеньером, техлидом или архитектором, но не знает чего-то из этого - у меня появятся большие вопросы к его любознательности, и как следствие квалификации.
Во-вторых, посты 17-19 содержат неплохой вариант предельно гибкой (а значит дорогой) архитектуры. Я с этими постами согласен процентов на 60-80 и уж точно лучше так, чем ни как - будет всё равно удобнее и дешевеле, чем Big Ball of Mud. Но, я бы их сильно сдобрил ФП и на мой взгляд сейчас для индустрии намного актуальнее вопрос того, как делать хорошие приложения, чем как делать гибкие во все стороны приложения.
Наконец, заключение серии навело меня на умную мысль.
Там мужик, в след за Эвансом и Мартином пишет, что именно ядро (бизнес-логика, юз кейсы, бизнес-правила) отличает систему от конкурентов. В целом, по большому счету, я согласен. Но как обычно есть но.
Допустим, все конкуренты используют условный Spring Data JPA. А мы, допустим, используем условный Spring Data JDBC и благодаря этому, допустим, наш продукт:
1) В целом быстрее для пользователей
2) Требует меньше ресурсов железа
3) Содержит меньше багов
4) Быстрее получает новые фичи
5) Благодаря пп 2-4, дешевле
Это всё разве не будет отличительным фактором (и конкурентным преимуществом)? Мне кажется будет.
В общем серию рекомендую к прочтению - она несёт больше пользы, чем вреда.
Я же, тем временем, тоже не катал вату. Я наконец определил содержание книги и написал черновик тизера первой части книги. Уже совсем скоро, я наконец опубликую кусок авторского контента.
#posts@ergonomic_code
@hgraca
The Software Architecture Chronicles
This post is the first of a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge.
По мотивам всё той же хроники архитектуры, перелистывал книгу по DDD Эванса и наткнулся на чистые функции прямо в оглавлении: SIDE-EFFECT-FREE FUNCTIONS.
С рекомендацией:
Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects
Всё, расходимся - вдумчиво читайте ДДД и будет вам счастье.
На самом деле нет😊 Мне всё ещё кажется, что мне есть что добавить к классикам - у меня есть свой взгляд на методику проектирования и я предлагаю более легковесный процесс и архитектуру.
#ddd@ergonomic_code #why_no_side_effects@ergonomic_code #whyfp@ergonomic_code
С рекомендацией:
Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects
Всё, расходимся - вдумчиво читайте ДДД и будет вам счастье.
На самом деле нет😊 Мне всё ещё кажется, что мне есть что добавить к классикам - у меня есть свой взгляд на методику проектирования и я предлагаю более легковесный процесс и архитектуру.
#ddd@ergonomic_code #why_no_side_effects@ergonomic_code #whyfp@ergonomic_code
Ну и наконец, линко-пост о кэшировании в Spring Data JDBC.
Про кеширование там полезно тем, что подсвечивают ряд граблей, свойственных JDBC, но самое полезное - раздел Why Spring Data does no caching, в котром автор пинает JPA.
Подписываюсь под каждым словом этого раздела всеми ~8 годами своих мучений с JPA/Hibernate в проде.
#posts@ergonomic_code #spring_data_jdbc@ergonomic_code
Про кеширование там полезно тем, что подсвечивают ряд граблей, свойственных JDBC, но самое полезное - раздел Why Spring Data does no caching, в котром автор пинает JPA.
Подписываюсь под каждым словом этого раздела всеми ~8 годами своих мучений с JPA/Hibernate в проде.
#posts@ergonomic_code #spring_data_jdbc@ergonomic_code
Spring Data JDBC - How do I implement caching?
Level up your Java code and explore what Spring can do for you.