Должны ли мы повторно использовать объекты JPA

Question

В настоящее время я работаю в компании с 6-7 проектами Java EE. Это проекты с несколькими модульными maven, которые являются довольно большими и служат для разных целей. Таким образом, их модели очень разные, но по большей части данные хранятся в одной базе данных.

Проблема, для меня, состоит в том, что, поскольку существует несколько областей перекрытия, они просто вводят существующие DAO на всю цепочку децентрации. Поэтому у меня есть

A-parent 
-A-JPA 
-A-DAO 

B-Parent 
-B-JPA 
-B-DAO 
-A-JPA 
-B-DAO 

и т. Д. И т. Д. Они действительно используют только 2 процента модели других проектов и соответствующие DAO.

Я пытаюсь отделить эти зависимости, просто дублируя требуемые объекты (и только включающие поля/сопоставления для вещей, которые действительно необходимы), так что один и тот же EJB не разворачивается 7 раз (или больше при кластеризации), но, видимо, я не делаю убедительных аргументов. Может ли кто-нибудь помочь мне указать статью с лучшими практиками для этой ситуации или помочь объяснить, как объяснить ему.

TLDR: Я хочу, чтобы каждый проект имел свой собственный набор объектов, даже если существует очень небольшое перекрытие, чтобы уменьшить зависимости между проектами, а также сделать так, чтобы мы не развертывали один и тот же EJB 7 раз. Мой босс считает, что нет ничего плохого в том, что они не связаны друг с другом. Могу ли я сделать это по этому поводу? Благодаря!

Answer 1

Если это единственная модель данных, которая поддерживается для использования различными приложениями, сущности персистенции (и даже их DAO) можно рассматривать как API Java для этой базы данных, и я бы поставил ее в центральную компонент. Некоторые организации могут даже управлять дизайном из базы данных вверх и реконструировать объекты персистентности, и в этом случае они будут одинаковыми или похожими для разных пользователей.

Является ли такой центральный компонент библиотекой (повторно используемой другими компонентами) или собственным EJB (который вызывается другими компонентами), я мог бы зависеть от желаемого поведения транзакций и кэширования приложения и того, как вы видите организуемые обязанности. В одном проекте мы строго придерживались правила, согласно которому каждая часть данных могла поддерживаться только одним компонентом (службой или EJB), а другим пришлось бы пройти через этот единственный компонент.

Если это общая модель домена, но каждый EJB реализует для нее собственное хранилище данных, то модель домена может быть разделена, и я бы не стал делиться объектами сохранения. Затем вы переходите к обсуждению совместного использования модели домена среди разных компонентов. Мир можно рассматривать несколько разными способами изнутри разных поддоменов, и я чувствую, что вы в конечном итоге создаете свои домены, несколько отличающиеся друг от друга в разных подсистемах, поэтому я бы, возможно, голосовал против повторного использования.

Каждый пробег может отличаться, и я могу видеть вещи по-другому, учитывая фактические обстоятельства конкретного проекта.