Есть ли польза от использования Maven Multimodule при работе в небольшом приложении?

Question

Мы создаем небольшое приложение, используя различные архитектурные уровни, такие как домен, интерфейс, инфраструктура и приложение. Это соответствует модели Onion DDD. Теперь мне интересно, есть ли какая-то польза от разделения приложения на многомодульный проект maven. Насколько я вижу сейчас, кажется, что все усложняется, чем нужно. Все приложение будет развернуто в виде одного файла WAR в контейнере Tomcat.

Answer 1

Разделение вашего приложения имеет смысл для следующего:

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

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

• Прощеремонтопригодность в долгосрочной перспективе.Может быть, теперь это похоже на небольшой проект.Через несколько месяцев все может выглядеть по-другому, и тогда вам потребуется больше рефакторинга, чтобы разделить вещи на логические единицы (модули).

• Концептуальная ясность (добавлено Адрианом Костером).

Относительно WAR: У вас может быть сборочный модуль, который собирает вещи и создает окончательный файл WAR из всех связанных модулей.

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

Answer 2

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

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

Answer 3

Краткий ответ: сегодня он маленький, завтра он станет больше и сложнее в обслуживании, повторном использовании, расширении, интеграции с другой системой и т. Д.

Answer 4

Насколько я знаю, Maven мало помогает для зависимостей WAR.Поскольку вы говорите об одной WAR, это никогда не должно быть проблемой.

Вы можете разделить java-классы на несколько подмодулей "jar", но если вы разбили проект WAR на несколько меньших WAR-файлов, используя своего рода "пересекающиеся «вещи запутываются сложнее.

Просто информация, один из наших проектов, содержит слишком много веб-страниц, поэтому мы решили разделить ее на несколько подмодулей WAR, однако сеанс не распределяется между различными развернутыми WARи мы не собираемся использовать Kerberos.Наконец, мы изменили много источников Glassfish, Jetty, MyFaces и т. Д., Чтобы они разрешали содержимое web.xml внутри JAR-файлов.И преобразовав весь проект в Facelets 2.0 (чтобы избежать зависимости JDK tools.jar и пользовательского обработчика ресурсов), единственной причиной является изменение подмодулей WAR на подмодули JAR и перемещение всех веб-приложений / страниц в ресурсы классов.Итак, вывод: Maven отлично справляется с зависимостями JAR, но без WAR или одной WAR.

EDIT Вы можете поместить applicationContext.xml в один из базовых подмодулей и импортировать его с помощью classpath:com/example/applicationContext.xml.В Spring 3.0 также есть поддержка аннотаций, вы можете сделать так, чтобы Spring автоматически сканировал их, а не объявлял их все в xml.

Answer 5

Разделение вашего проекта на несколько проектов maven полезно, если вы хотите повторно использовать ваши классы в другом проекте или если ваши проекты развернуты в разных конфигурациях.

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

Для дальнейшего развития клиентов можно использовать и первый проект.

Использование родительского проекта для управления зависимостями от общих проектов (таких как ведение журнала) и различных профилей и конфигураций сборки.