Как структурировать приложения как несколько проектов и как называть пакеты в Java?

Question

Я хотел бы знать, как вы настраиваете свои проекты на Java. Например, в моем текущем рабочем проекте, шестилетнем приложении J2EE с примерно 2 миллионами LoC, у нас есть только один проект в Eclipse. Структура пакета разбита на уровни и затем домены, поэтому она следует рекомендациям Sun / Oracle . Огромный муравьиный скрипт собирает разные jar-файлы из этой единственной исходной папки

Лично я думаю, что было бы лучше иметь несколько проектов, по крайней мере для каждого уровня. Недавно я играл с такой структурой проекта:

• Domainproject (содержит только аннотированные pojos, необходимые для всех других проектов)
• Datalayer (только постоянство)
• Businesslogic (услуги)
• Presenter
• Посмотреть

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

Имеет ли это смысл для вас? Используете ли вы разные подходы и как они выглядят?

Кроме того, я изо всех сил пытаюсь правильно назвать мои пакеты / проекты. Прямо сейчас, вышеупомянутая структура проекта отражается в именах пакетов, например. de.myapp.view и продолжается некоторыми техническими подпапками, такими как внутренние или интерфейсы . Чего мне не хватает здесь, и я не знаю, как это сделать правильно, так это различия между определенным доменом. Когда проект становится больше, было бы неплохо распознать конкретный домен, но также и технический детали для более удобной навигации по проекту.

Это приводит ко второму вопросу: как вы называете свои проекты и пакеты?

Answer 1

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

Каждая библиотека / приложение будет иметь свой собственный проект с модульными / функциональными тестами и конечным результатом (в вашем случае, артефактом Maven, который вы можете сохранить и соответствующим образом версия).

Единственной головной болью является управление интерфейсами и связями между этими компонентами. Ключевым моментом здесь является эффективная среда тестирования интеграции.

Answer 2

Это приводит ко второму вопросу: как Вы называете свои проекты и пакеты

Для имен проектов я предпочитаю внутреннее имя, такое как Longhorn = WinVista. Это имя никогда не меняется (как и имена моих детей). Таким образом, маркетинг и т. Д. Можно зарегистрировать любое имя, ребрендинг и т. Д.

Пакеты - это вопрос (личных) предпочтений и стиля. И обычно старший программист решает структуру. Конечно, существуют некоторые «стандарты», такие как «gui» для классов пользовательского интерфейса, «util», «misc», «impl» для реализаций интерфейса, «domain» для классов объектов домена и т. Д., Которые следует использовать последовательно и выражать свой стиль.