Структура каталогов Spring с интерфейсами (лучшие практики)

Question

В настоящее время я пишу свое первое приложение Spring (Spring boot + hibernate).Я проверил структуру каталогов лучших практик по их документации здесь .Это имеет смысл.

Вопрос 1:

У меня есть interface (или Abstract class), который расширяется на несколько подклассов, и поэтому мне нужен только @Repository дляродительский класс.Я решил сделать это следующим образом:

com
 +- example
     +- myapplication
         +- Application.java
         |
         +- message
         |   +- AbstractMessage.java
         |   +- IMessageRepository.java
         |   +- MessageRepositoryImpl.java
                +- messageTypeA
                |  +- messageTypeA.java
                |  +- messageTypeAService.java
                +- messageTypeB
                |  +- messageTypeB.java
                |  +- messageTypeBService.java

Вопрос 2:

Теперь у меня есть новый entity для сохранения, который называется Group.Поэтому я могу добавить каталог Group на том же уровне, что и Message.Тем не менее, этот Group на самом деле является частью Message (например, логически), поэтому было бы целесообразно, если бы он был частью того же каталога message ( единственная причина, по которой мы сохраняем их как разныесущностей, потому что имеет больше смысла выводить аналитику таким образом ).Кроме того, я даже использую тот же MessageRepository, чтобы сохранить его (я просто добавил второй метод в интерфейс, например, так:)

public interface MessageRepository {

    void insert(AbstractMessage message);

    void insert(AbstractMessage message, AbstractGroup group);
}

Было бы что-то вроде следующего хорошо?Или каждый entity должен иметь свой собственный пакет?Я обдумываю это?

com
 +- example
     +- myapplication
         +- Application.java
         |
         +- message
         |   +- AbstractMessage.java
         |   +- IMessageRepository.java
         |   +- MessageRepositoryImpl.java
             |  +- messageTypeA
             |     +- messageTypeA.java
             |     +- messageTypeAService.java
             |  +- messageTypeB
             |     +- messageTypeB.java
             |     +- messageTypeBService.java
             |
             +- group
                +- AbstractGroup.java
                +- GroupTypeX.java // same service as message, just different entity
                +- GroupTypeY.java // same service as message, just different entity

Answer 1

Я согласен с ответом @LppEdd выше.Только один вопрос, что вы имеете в виду, когда говорите

(единственная причина, по которой мы сохраняем их как различные объекты, заключается в том, что имеет больше смысла выводить аналитику таким образом).

Answer 2

Это скорее вопрос, основанный на мнении, но я хотел бы дать вам пару предложений.

Прежде всего, naming .
Префикс I включенИнтерфейсы - это «древняя» техника IBM для их распознавания.Пожалуйста, не делайте этого, это избыточно, это не имеет смысла в новой среде.Что такое I-MessageRepository?!
Вы найдете этот тип именования в основном для Eclipse RCP проектов или любого продукта IBM.

Тогда имя реализации.Не используйте суффикс Impl, он ничего не говорит человеку, который читает или редактирует ваш код.
Дайте ему имя, в котором будет указано его назначение или область действия домена.

ActiveMQMessageRepository
FileMessageRepository
TcpMessageRepository

---

Во-вторых, Repositories.
Хранилища должны управлять одним типом объектов, но не более одного.Используйте Services, чтобы координировать несколько Repositories.Это упростит отладку для всех и отсоединит много кода.

---

В-третьих, packages.
Старайтесь всегда иметь плоскую структуру пакета.Плоская структура проще в обслуживании, на нее легче смотреть, легче для понимания.Не создавайте десятки подпакетов, таких как

- messages
   - services
       MessageService
     - implementations
        ...
   - repositories
       MessageRepository
     - abstract
         AbstractMessageRepository
     - implementations
         TextMessageRepository
   - exceptions
     - runtime
     - checked
         UnsupportedMessageException

Ужасно и бесполезно.И вы не можете использовать видимость пакета .

Так что держите messages и groups на отдельных пакетах и ​​присваивайте им свои Repository.

Предоставлять интерфейсы из пакетов, а не конкретные реализации. (когда это возможно)