How to split a huge project into maven modules-CodePudding

I have a project in OSS consisting of 20,000 lines of code and 300 classes. Also, These classes are divided into two modules: front-end and back-end.

A problem has recently arisen. It is that there are many classes in one module and it takes a long time to compile. By changing just one line, Maven will try to rebuild all the classes in that module.
To solve this, I thought of further dividing it into several modules.

The current package configuration is as follows:

.
|
|-FrontModule/
|
|-BackEndModule/
| |-com.example.package/
| | |-resolver/
| | | |-...
| | |-loader/
| | |-installer/
| | |-BackendDaemon.java

We are considering refactoring this as follows:.

.
|
|-FrontModule/
|
|-BackEndModule/
| |-com.example.package/
| | |-BackendDaemon.java
|-ResolverModule/
| |-...
|-LoaderModule/
| |-...
|-InstallerModule/
| |-...

Currently, representative instances of resolver, loader, and installer are stored in BackendDaemon's constants. The installer also operates using an instance of resolver in BackendDaemon.

In this situation, I believe that refactoring a package into a module will invariably result in interdependencies somewhere.

Is there any way or design to somehow split this huge code into modules?

I would appreciate it if someone could answer my question.

Also, since I am using a translator to translate from Japanese, if there are expressions that are difficult to understand or things that are not conveyed, please let me know.

Thank you.

CodePudding user response：

A good way to do this is following the so-called onion architecture, see for example https://dev.to/barrymcauley/onion-architecture-3fgl. The basic idea is that you have your domain/service module at the core of your model. Being at the center means that it doesn't have any dependencies towards other modules. Around it you get in the first layer of modules where you put for example access to a database, then another layer with interfaces to other systems and finally user interfaces in the last layer of modules. The idea is that you only make dependencies that point inward and that way you prevent dependency loops.

I don't know what your application is about, but going by what you put in the question I'd say you have a domain module at the core, then a resolver in the 2nd layer. The next layer has your loader and installer. You already made the outermost layer in a separate module in the past, which is the front module.

Also keep in mind that you can use dependency inversion (the D of the famous SOLID acronym) to make sure that your dependencies point the right way. So if your domain module needs to resolve something, it'll use a 'ResolverInterface' from the domain module that is implemented by a class inside the resolver module. This way there is only a dependency from the resolver module towards the domain module. The dependency inversion framework (Spring is a very popular one) will make sure that the implementation of that 'ResolverInterface' will be available at runtime via Autowiring.

CodePudding user response：

I think you should ask again why you want to split the project, using JRebel can optimize your compile time. Otherwise using a maven pom parent file with its submodules is a way! or even use other build tools or build flows with a little scripting. But I recommend organizing your project not only in IDE somehow conceptually, first pick an architecture base on your project scalability, prerequisites, and feature list then plan how to move step by step.