我有一个由20,000行代码和300个类组成的OSS项目。此外，这些类分为两个模块:前端和后端。
最近出现了一个问题。一个模块中有很多类，需要很长时间来编译。只需更改一行代码，Maven就会尝试重新构建该模块中的所有类。
为了解决这个问题，我想把它进一步分成几个模块。
当前的包配置如下:
.
|
|-FrontModule/
|
|-BackEndModule/
| |-com.example.package/
| | |-resolver/
| | | |-...
| | |-loader/
| | |-installer/
| | |-BackendDaemon.java
我们正在考虑这样重构:
.
|
|-FrontModule/
|
|-BackEndModule/
| |-com.example.package/
| | |-BackendDaemon.java
|-ResolverModule/
| |-...
|-LoaderModule/
| |-...
|-InstallerModule/
| |-...
目前，解析器、加载器和安装程序的代表性实例存储在BackendDaemon的常量中。安装程序还使用BackendDaemon中的解析器实例进行操作。
在这种情况下，我相信将一个包重构成一个模块将不可避免地导致某个地方的相互依赖。
是否有任何方法或设计以某种方式将这个巨大的代码分成模块?
如果有人能回答我的问题，我会很感激的。
另外，由于我使用翻译人员从日语翻译，如果有难以理解的表达或没有传达的内容，请让我知道。
谢谢。
这样做的一个好方法是遵循所谓的洋葱架构，例如参见https://dev.to/barrymcauley/onion-architecture-3fgl。基本思想是将域/服务模块置于模型的核心。处于中心意味着它对其他模块没有任何依赖。在它的周围，你进入第一层模块，例如，你可以访问数据库，然后是另一层与其他系统的接口，最后是模块的最后一层用户接口。这个想法是你只创建指向内部的依赖，这样你就可以防止依赖循环。
我不知道你的应用程序是关于什么的，但是根据你在问题中提出的内容，我想说你在核心有一个域模块，然后在第二层有一个解析器。下一层是加载器和安装程序。在过去，您已经在一个单独的模块中制作了最外层，也就是前面的模块。
还要记住，你可以使用依赖倒置(著名的SOLID首字母缩略词中的D)来确保你的依赖指向正确的方向。所以如果你的域模块需要解析一些东西，它会使用一个来自域模块的'ResolverInterface'，它是由resolver模块中的一个类实现的。这样，解析器模块对域模块只有一个依赖关系。依赖反转框架(Spring是一个非常流行的框架)将确保'ResolverInterface'的实现将通过Autowiring在运行时可用。
我认为您应该再问一下为什么要拆分项目，使用JRebel可以优化编译时间。否则，使用maven pom父文件及其子模块是一种方法!或者甚至使用其他构建工具或带有少量脚本的构建流。但是我建议不仅在IDE中从概念上组织项目，首先根据项目的可伸缩性、先决条件和特性列表选择一个体系结构，然后计划如何一步一步地移动。