Луковая архитектура с использованием объекта JPA в качестве объекта домена - PullRequest
Новая
       28

Луковая архитектура с использованием объекта JPA в качестве объекта домена

1 голос
/ 13 апреля 2020

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

Использование отдельных классов доменов для Aggregate root / Aggregates..et c с репозиториями доменов, чтобы обернуть репозитории Spring JPA и использовать конвертеры для сопоставления сущностей JPA <> Доменные объекты только с необходимыми data

  • Ленивая загрузка собирается быть отдана, если только мапперы / конвертеры не обрабатывают это внутри репозиториев домена, но это излишне.

  • Когда Сохраняя объекты, могут быть связанные Агрегированные корни (отношения один ко многим), которые позже в сложных логах c, мне пришлось очень постараться позаботиться о состоянии сущности Домена, чтобы передать его в хранилище домена и либо заполнить его всеми связанных данных или просто сопоставьте их (другой метод в конвертере) с данными отношений (каскадное сохранение не применяется к JPA)

  • Множество дублированного кода, чтобы избежать таких ситуаций даже для очень простых варианты использования

Или Использовать объекты JPA в качестве объектов моего домена и т. д. r существует несколько примеров / мнений по этому поводу, например

https://github.com/citerus/dddsample-core/tree/Spring_Annotations_Autowire

http://www.javamagazine.mozaicreader.com/MayJune2018/Twitter# & pageSet = 50 & page = 0

Должны ли сущности JPA и DDD сущностей быть одинаковыми классами?

DDD, доменные сущности / VO и JPA

Как реализовать DDD с использованием Spring Crud / Jpa Repository

С другой стороны, существуют такие мнения

Является ли хорошей практикой использование объектов JPA как модели предметной области?

Мой вопрос, в долгосрочной перспективе, из опыта

  • Что будет стоить больше усилий и времени?
  • Являются ли оба подхода приемлемы в качестве практики?
  • Каковы плюсы и минусы обоих?

1 Ответ

1 голос
/ 15 апреля 2020

Что будет стоить больше усилий и времени?

Разделение почти всегда стоит. Это компромисс!

Являются ли оба подхода приемлемыми в качестве практики?

Да. Я вижу, что есть много противоречивых мнений по обоим подходам, но на самом деле, это просто мнения. Оба применяются и стоимость.

Каковы плюсы и минусы обоих?

Использование сущностей JPA в качестве доменных сущностей действительно 1 - сокращает временные затраты, условно. 2- Также позволяет использовать ленивую загрузку со связями, избегая большего количества кода в сервисе приложений, что, если вы не следите за ссылками на другие агрегаты по идентификатору, который также основан на мнениях, но действительно стоит ленивая загрузка JPA.

Одним из недостатков этого подхода является модульное тестирование, как мне кажется. Модульный тест не должен зависеть от запуска контейнера, базы данных ... et c. Стоит чисто проверить бизнес логи c. Но это не оптимально возможно с такими структурами. См. Этот ответ, например:

Объект JPA должен быть модульно протестирован и как?

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

Также автоматическая c отложенная загрузка ORM не будет использоваться и выполняться легко. Либо

1- Вы помещаете ссылку на другие агрегаты в качестве члена в агрегате root (нарушение правила ссылки на идентификатор агрегата) и обрабатываете это в преобразователях

2- Вы получаете из репозитория нужны только данные агрегата root с идентификатором другого агрегата в качестве ссылочных элементов. Это делается с помощью четко определенных запросов в реализации репозитория, поэтому это много написания и настройки запросов. Избегайте использования значений по умолчанию, которые возвращают полные сущности JPA с готовыми ссылками на ленивую загрузку.

...