maven-多模块项目的个人理解（1.0.1）

应用场景

在程序员加班成疯的当下，一切皆需要拿来主义来完成既定任务的高效交付。我们需要把别人造好的轮子拿来使用。同时我们自己也会建造一些轮子。对于这些轮子，我们需要一种相对于复制粘贴来讲更加优雅的方式来使用。

对于大型的应用开发场景，我们可以按照高内聚低耦合的原则，将应用分解成若干个独立的模块，分别进行开发，每个模块的依赖较低，耦合较高。既可以解决多人开发的合并代码相互干扰问题，又可以完成后续功能的灵活装配。

技术方案

maven+nexus多模块打包

具体应用一

工具方法、可复用轮子抽离（common）、后续项目为一个新的模块(project)，团队历史中一直维护一套代码来完成若干项目开发工作。

这种分模块方式适合技术能力较弱，短平快的开发项目团队。能保证大家造的轮子可以便捷使用，新成员可以快速学习和参考沉积代码的使用，同时也方便主程序审阅代码。

具体应用二

这一类分包模式就比较复杂，按照高内聚低耦合策略，将项目的模块、sevice、api、dao、等划分成若干模块，每个模块可以的每个类都可以测试。属于大型项目、长期产品、高素质团队使用的模式。这个模式呢，我只是在网络上看到别人使用过，由于自身工作经历就不仔细描述。参考：使用Maven进行多模块拆分

注意事项

高耦合低内聚：各个模块之间一定要满足高耦合低内聚的划分原则，不能盲目套用别人的模块划分策略和方案。按照自己的理解，团队的代码规划能力决定了模块划分的最终结果，强行划分会导致开发成本浪费，最大可能保证项目模块的内聚特性。

依赖的传递性：多个模块必然会有依赖关系，我们需要保证模块的依赖顺序，最好在规划时确定每个模块的依赖关系，梳理好传递性，避免依赖的冲突。