Я посмотрел 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 основными сложностями будут изучить саму 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