为什么你细分为内部项目的maven模块？

Question

我们在我们的项目中持续讨论了我们的maven模块的粒度。我们已经认识到，框架（如spring）和内部应用程序的需求可能存在差异，这些应用程序始终以单片方式部署。

我们也同意隐藏适配器在独立API模块后面的外部系统的实现细节是相当明智的，因此实现类不会渗入到主要实现的类路径中。 as 但是，这就像我们去。这是一个web项目，所以我们有像“网络”，“核心”和“适配器”等模块。我们有多个后端，但我们不需要可插拔性。

你用什么标准模块化maven？你为Web项目制作了哪些模块？

Answer 1

在我看来，项目部门应该是非常细致的，即使是“只有一个webapp”。

我会为数据访问层接口和实现，业务层接口和实现以及webapp本身制作单独的项目。我还会制作至少一个“共同”项目，用于包含与其他项目相关的代码。但这仅仅是个开始。无论正在开发的应用程序（字符串，日期，反射等）如何，我都会毫不犹豫地提取相关实用程序类的commons-util项目。我也会在做测试时做一个有用的工具项目（commons-test）。这只是下一步...;）

如果我写了一般有用的代码与hibernate相关，我会把它放在一个hibernate-utils项目中。有用的Spring实用程序将用于spring-utils项目等。在这样做时，许多项目只包含一个或几个包，而包通常包含几个类。

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

我也发现新开发人员更容易得到一个结构的挂起，因为项目变得更小，更易于管理;当你觉得你不必承受任何事情时，开始编码会更容易。

作为细粒度方法的最后一个优点，构建时间减少是因为您不必每次都构建一切。