Java 为什么要将内部项目细分为maven模块？

我们在项目中经常讨论maven模块的粒度。我们已经同意，框架（如spring）和内部应用程序的需求可能存在差异，而内部应用程序总是以单片方式部署的

我们还同意，将外部系统适配器的实现细节隐藏在单独的API模块后面是相当明智的，这样实现类就不会流入主实现的类路径。 作为 但这就是我们要做的。这是一个web项目，所以我们有“web”、“核心”和“适配器”等模块。我们有多个后端，但不需要可插拔性

---

在maven中模块化使用什么标准？您为web项目制作了哪些模块？

在我看来，项目划分应该是非常细粒度的，即使是“仅一个web应用程序”

我将为数据访问层接口和实现、业务层接口和实现以及webapp本身制定单独的项目。我还将创建至少一个“commons”项目，用于包含与多个其他项目相关的代码。但这仅仅是开始。无论开发的应用程序是什么（字符串、日期、反射等），我都会毫不犹豫地为相关的实用程序类提取commons util项目。在进行测试时，我还将为有用的实用程序创建一个项目（commons test）。这只是下一步…；）

如果我编写了与hibernate相关的通用代码，我会将其放在hibernate utils项目中。有用的Spring实用程序可以放在Spring utils项目中，等等。这样做时，许多项目将只包含一个或几个包，这些包通常只包含几个类

我这样做的理由是，它帮助我思考我编写的代码。这是真正的业务逻辑，还是一般的字符串操作、日期操作、特定于Hibernate的逻辑等？我的层变得更干净，在包和项目之间获得循环依赖关系变得更加困难（我们不想要这些）。此外，在其他项目中重用代码变得更加容易。总会有其他的项目

我还发现，新开发人员更容易掌握结构，因为项目变得更小，更易于管理；当您觉得不必理解所有内容时，开始编写代码就更容易了

---

作为细粒度方法的最后一个优势，构建时间缩短了，因为您不必每次都构建所有内容。

您没有发现IDE的内存需求随着模块数量的增加而激增吗？嗯，事实上没有，但我对运行IDE的进程的堆大小非常慷慨。更少的模块需要更少的内存，这可能是对的，但到目前为止这还不是一个问题。现在4GB的ram价格合理……您如何在这种结构中管理依赖版本？我使用了类似的方法，但是发现我的模型对象几乎被所有的东西都使用，而且当模型层的内部发生变化时，到处都要切换版本是一件很麻烦的事情。所有的小模块都使用快照版本。但它确实在IDE中使用了大量内存来处理所有这些模块。500mb到1gb的内存并不少见。使用32位XP和最大3gb内存可能会有点痛苦