Как разбить огромный проект на модули maven
У меня есть проект в OSS, состоящий из 20 000 строк кода и 300 классов. Кроме того, эти классы разделены на два модуля: фронтенд и бэкенд.
Недавно возникла проблема. Дело в том, что в одном модуле много классов и компилируется долго. Изменив всего одну строку, Maven попытается перестроить все классы в этом модуле. Чтобы решить эту проблему, я подумал о дальнейшем разделении на несколько модулей.
Текущая конфигурация пакета выглядит следующим образом:
.
|
|-FrontModule/
|
|-BackEndModule/
| |-com.example.package/
| | |-resolver/
| | | |-...
| | |-loader/
| | |-installer/
| | |-BackendDaemon.java
Мы рассматриваем рефакторинг следующим образом:
.
|
|-FrontModule/
|
|-BackEndModule/
| |-com.example.package/
| | |-BackendDaemon.java
|-ResolverModule/
| |-...
|-LoaderModule/
| |-...
|-InstallerModule/
| |-...
В настоящее время репрезентативные экземпляры распознавателя, загрузчика и установщика хранятся в константах BackendDaemon. Установщик также работает с экземпляром распознавателя в BackendDaemon.
В этой ситуации я считаю, что рефакторинг пакета в модуль обязательно где-то приведет к взаимозависимостям.
Есть ли способ или дизайн как-то разделить этот огромный код на модули?
Буду признателен, если кто-нибудь ответит на мой вопрос.
Кроме того, поскольку я использую переводчик для перевода с японского, если есть выражения, которые трудно понять, или вещи, которые не переданы, пожалуйста, дайте мне знать.
Спасибо.
Ответы 2
Хороший способ сделать это — следовать так называемой луковой архитектуре, см., например, https://dev.to/barrymcauley/onion-architecture-3fgl. Основная идея заключается в том, что в основе вашей модели лежит модуль домена/службы. Нахождение в центре означает, что он не имеет никаких зависимостей от других модулей. Вокруг него вы получаете первый слой модулей, где вы размещаете, например, доступ к базе данных, затем другой уровень с интерфейсами к другим системам и, наконец, пользовательские интерфейсы в последнем слое модулей. Идея состоит в том, что вы создаете только те зависимости, которые указывают внутрь, и таким образом вы предотвращаете циклы зависимостей.
Я не знаю, о чем ваше приложение, но исходя из того, что вы задали в вопросе, я бы сказал, что у вас есть модуль домена в ядре, а затем преобразователь на втором уровне. На следующем уровне есть ваш загрузчик и установщик. Вы уже сделали самый внешний слой в отдельном модуле в прошлом, который является передним модулем.
Также имейте в виду, что вы можете использовать инверсию зависимостей (D в известной аббревиатуре SOLID), чтобы убедиться, что ваши зависимости указывают правильный путь. Поэтому, если вашему модулю домена нужно что-то разрешить, он будет использовать «ResolverInterface» из модуля домена, который реализован классом внутри модуля разрешения. Таким образом, существует только зависимость от модуля распознавателя к модулю домена. Фреймворк инверсии зависимостей (весьма очень популярен) гарантирует, что реализация этого «ResolverInterface» будет доступна во время выполнения через Autowiring.
Я думаю, вы должны еще раз спросить, почему вы хотите разделить проект, используя JRebel, вы можете оптимизировать время компиляции. В противном случае можно использовать родительский файл maven pom с его подмодулями! или даже использовать другие инструменты сборки или создавать потоки с небольшим количеством сценариев. Но я рекомендую организовать свой проект не только в IDE как-то концептуально, сначала выбрать архитектуру, основанную на масштабируемости вашего проекта, предварительных требованиях и списке функций, а затем спланировать, как двигаться шаг за шагом.