Як JPA/Hibernate реалізовує ідеї "Domain-Driven Design".

Рет қаралды 2,821

Күн бұрын

👉 Приєднуйся до Bobocode Community: www.bobocode.com/
________________________________________
Patreon: / bobocode
GitHub: github.com/bobocode-projects
Telegram: t.me/bobocode
LinkedIn: bit.ly/2RWPQF5
Twitter: bit.ly/3vaQiOl
Тарас в LinkedIn: bit.ly/2ElWg8J
Тарас в Twitter: bit.ly/33Pmuwg
________________________________________
33-те заняття тренувальної програми Ultimate Enterprise Java (2021).
УВАГА! Відеозапис не містить активної частини заняття.
00:00 - Нарізка основних моментів
1:49 - Початок
3:17 - Для чого потрібен Domain driven design?
3:31 - Що таке Домен?
6:03 - Різниця між ентіті і value моделями
9:19 - Створюємо демо проект по DDD
18:00 - Як JPA I Hibernate імплементували ідею DDD
20:00 - як порівнювати Entity?
24:36 - анотація @NaturalId
25:07 - Робота із stateless сутностями. Value-об‘єкти
28:52 - Анотаціі @Embedded I @Embeddable
29:53 - Як працювати зі списком value - об’єктів? Анотаціі @ElementCollection I @CollectionTable
33:11 - Наслідування сутностей. Анотації @Inheritance I @MappedSuperclass
35:48 - Як додати індекси в таблицю на стороні Java?
41:42 - Імплементуємо бізнес логіку по DDD
48:45 - Що таке агрегати?
#opensource #java #education

Пікірлер: 7

@Bobocode Жыл бұрын

👉 Навчання від Bobocode: bit.ly/3IRrJhj

@user-wv7pk5sh3h Жыл бұрын

Я правильно розумію, що якщо ми працюємо з ДТОшками які вигружаємо за бази замість ентітів то ми ці внутрішні методи повинні робити там, що повинно порушувати ідею ДТО як Data Transfer Object. І ще щодо розділення шарів, по Clean Architecture нам не радять тримати всередині апплікейшену Ентіті, тобто для цього ми використовуємо маппери або одразу дістаємо ДТО з Хайбернейту, в такому випадку ми також внутрілню логіку повинні тримати в domain model об'єктах? Чи всеж робота з Ентіті у сервісах це цілком нормальна справа?

@Bobocode Жыл бұрын

Треба розуміти, що оптимізація роботи запитів не завжди вписується в ідею Clean Architecture і чіткого розділення.

@user-gg2wf7yf8i Жыл бұрын

Дуже гарне питання. Я теж хотів на це звернути увагу. Хайбернейт - це ORM. Тобто до нього треба ставитись як до мапера між об'єктом бази даних і об'єктом в джаві. І це ну ніяк не корелюється з доменними об'єктами. Він допомагає робити запити в БД та не конвертувати result Set в об'єкт, от і вся задача, яку виконує хайбернейт, і то не завжди дуже добре. Той факт, що хайбернейт називає свої об'єкти entity, лише більше заплутує. Для супер простих проектів на колінці можна об'єднати доменний об'єкт з хайбернейт об'єктом, але це не вірно з точки зору архітектури. З точки зору архітектури, модуль доменів не повинен залежати в коді від реалізацій (dependency inversion principle), а хайбернейт вставляє себе в саме серденько проекту, чим зміщує фокус з реального домену (банківський застосунок) на домен бази даних. Правильніше було б з точки зору архітектури робити модуль з доменом, потім сервіси, які в коді залежать від домену, репо модуль, який в собі мав би ORM, і міг конвертувати хайбернейт ентіті в доменний об'єкт. Тобто на рівні сервісів про хайбернейт ніхто ще не повинен знати, це деталі.

@feoktant Жыл бұрын

Ідея репозиторіїв у DDD - що вони частина домену. І в ньому методи відповідають ubiquitous lang. Коли ж створюється інтерфейс ApplicationRepository десь на рівні infra/application, який наслідує JpaRepository, DDD випаровується. Через анотації маппінгу, моделі не видно взагалі. Вона потонула десь у коді JPA. Це той випадок, коли краще XML. Писати індекси БД на рівні моделі - це не те про що писав Еванс і послідовники. Кожен ValueObject - кандидат на Java Record, по класиці імутабельні, думаю хібернейт спрацює. Імхо, анотований Хібернейт зупинив ДДД у Джаві, найцікавіші статті/книжки з прикладами на Сі шарп

@user-gg2wf7yf8i Жыл бұрын

Згоден. Jpa - це про ОРМ в першу чергу. І об'єкт, який мапиться на рядочки бази даних, нічого спільного з доменом не має. Можливо, вони повністю співпадають по полям, але в сутності вони абсолютно різні. Доменні об'єкти - це ядро застосунку, а орм об'єкти - це деталі реалізації репозиторія, якого на рівні домену і сервісів не має бути.