Пружинный загрузочный мультимодуль и баночка для жира с общими функциями

Question

Эксперты,

Мне нужен совет специалиста о том, как подходить к приведенному ниже варианту использования при весенней загрузке.

1. Мне нужен мультимодульный подход maven к моему проекту .
2. Мне нужно иметь один JAR-файл в качестве результата окончательного процесса сборки.
3. Должны быть общие модули для контроллеров, доступа к данным и других функций
4. Другие модули должны быть созданы на основе функциональной области, например, для модуля для расчета заработной платы, для модуля Admin et c et c.
5. Каждый функциональный модуль домена будет иметь свои собственные контроллеры, расширяющие общий контроллер, исключение обработчик и т. д.
6. Каждый модуль также будет иметь собственный набор страниц листа тимьяна.

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

Вот проблемы, которые я могу ощутить, используя этот подход.

1. Где я могу добавить веб-зависимость Spring? Если я добавлю в родительский pom - он будет реплицирован по дочерним элементам, и при загрузке каждого модуля будут возникать проблемы с конфликтом портов. та же проблема возникнет и в тот момент, когда я добавлю его в два дочерних модуля.

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

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

Answer 1

AD1. Они не будут, если вы не пытаетесь настроить независимый контекст приложения в каждом модуле. Конечно, вы можете сделать это (это может быть сложно, но я считаю, что это достижимо), но для меня это излишество. Лично я думаю, что лучше иметь один контекст приложения и полагаться на компоненты сканирования, которые присутствуют в classpath.

AD2. Структура в Maven может быть немного сложной и на первый взгляд ошеломляющей, но это имеет смысл. Вот как я это вижу:

1. Создайте родительский модуль, который будет агрегировать каждый модуль в проекте и объявлять зависимости библиотеки / плагина для подмодулей.
2. Создать 1-N общих подмодулей, которые будут использоваться в других модулях. Приходят общие логики c, utils, et c.
3. Создание 1-N подмодулей, которые будут обрабатывать ваши бизнес-логи c
4. Создание подмодуля приложения, создающего контекст приложения и загружает конфигурацию и компоненты из classpath
5. Создайте подмодуль, который будет отвечать за процесс упаковки, либо war, jar, uber-jar или что-либо еще, что вы пожелаете. Maven jar плагин должен сделать это для вас. Для исполняемого uber-jar у вас есть специальный инструмент от Spring.

Теперь вы можете выбрать три способа (эти способы, как я знаю) загрузки ваших модулей. 1. Включите некоторые модули в сборку maven на основе конфигурации сборки через профили maven и позвольте контейнеру spring Io C загрузить все компоненты, которые он найдет в пути к классам 2. Включите все модули в сборку maven и загрузите их в зависимости от активной пружины профили - вы можете думать об этом как о признаке функции. Вы комментируете свои компоненты или класс конфигурации с помощью @Profile ("XYZ"), сообщая контейнеру Spring Io C, создавать ли экземпляр компонента или нет. Вам потребуется (наиболее гибкое решение) предоставить файл свойств, который сообщает Spring, какие профили активны и, следовательно, какие модули должны быть загружены. 3. Сочетание этих двух выше.

Плюсы решения 1:

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

Решение 1, контраст:

• Дескриптор проекта в maven может взорваться, поскольку у вас может быть много разных профилей

Плюсы решения 2:

• поддержка модулей из кода довольно проста и увлекательна
• меньше беспорядка в дескрипторе проекта

Решение 2 контрастное:

• кто-то может запустить модуль, который не предназначен для запуска, поскольку он присутствует в classpath, но только исключен во время выполнения с помощью активных профилей Spring
• файл окончательной сборки может иметь избыточный вес - un используемый код все еще присутствует в коде
• сборка может занять больше времени - неиспользуемый код будет скомпилирован

Резюме:

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

За последние 8 лет использования maven я честно и настоятельно рекомендую использовать gradle, так как гораздо более гибкий, чем maven. Maven действительно отличный инструмент, но когда дело доходит до странной настройки, он часто терпит неудачу, поскольку его возможности сборки зависят от плагинов. Вы не можете написать фрагмент кода на лету, чтобы выполнить какое-то пользовательское поведение при сборке при создании проекта, для этого у вас должен быть специальный плагин. Если такой плагин существует, то это нормально, если его нет, вы, вероятно, в конечном итоге будете писать свой собственный и обрабатывать его отгрузку, поэтому любой сотрудник вашей компании может легко выполнить сборку проекта.

Надеюсь, это поможет. Веселись;)