Куда поместить мои классы фреймворка, используя соглашение об использовании по отдельности?

Question

Я много читал об условном соглашении об именах пакетов. Поэтому я решил попробовать в новом проекте. Тем не менее, я не уверен, как его следует назвать моими пакетами, которые будут использоваться большинством моих классов, поскольку я использую огромную структуру, например, Spring и Hibernate.

Это как обрабатывать наши Spring contexts классы:

И наш класс database доступа, который управляет соединениями и так далее.

У меня есть проект об этом: используя общий пакет для этих структур, как:

com.company.project.common.spring 
com.company.project.common.database 

Но я боюсь, что это все еще выглядит package-by-layer немного. :) Как создать пакеты, которые будут доступны моим feature classes?

Answer 1

Общая рекомендация «пакет по функции, а не слой». То, что я часто делаю, это «пакет по функции», , затем слой ». Я также считаю, что пакеты верхнего уровня должны быть «функциональными» компонентами (независимо от того, какие функции). Но мне также нравится разделять слои на подпакеты.

С моей точки зрения, связанный с каркасом код сам по себе не представляет собой «функции» (как в «важных, высокоуровневых аспектах проблемной области»), поэтому поэтапная функция не делает много смысл здесь. Но все же, это важный код, и вам нужен подход к его структурированию.

Я обычно используют два подхода:

Если мне нужно расширить или увеличить библиотеки я использую, я структурировать пакеты параллельно пакета структуре библиотеки. Например, если мне понадобится реализовать новый формат чисел для Spring, я, вероятно, буду называть пакет com.acme.foo.springframework.format.number, параллельный org.springframework.format.number.

Однако, если мне нужно реализовать общие базовые классы для слоев функций, это, вероятно, что-то вроде com.acme.foo.common.<layer>. Например, если у нас есть пакеты для доступа к данным какой-либо функции, com.acme.foo.common.dataaccess может содержать базовые классы для уровней доступа к данным всех функций.

Оба подхода используются параллельно. Вам просто нужно решить, является ли какой-то класс фреймворком или расширением библиотеки (можете ли вы представить, как использовать его вне этого проекта?) Или он ближе к слоям вашего проекта.