在我的职业生涯中，我主要从事中小型java项目。我最近在eclipse中看到了一个由30个项目组成的巨大项目。我真的不明白创建许多小项目然后维护项目间依赖关系的概念。什么时候我们更喜欢这样而不是简单地把东西打包?
我猜这是一个maven的事情(主要是使用Ant)。我也一直在阅读Maven的模块概念——我在网上看到一些链接，建议在父模块下为web、dao和服务层创建不同的模块。这真的是一种常见/最佳实践吗?
有或没有maven -这样的划分真的使生活更容易吗?把所有的东西都放在一个项目中，并为不同的层定义良好的包结构，这不是更紧凑吗?
当有需要时，将项目分成API、实现、web等组件是很常见的。大项目就是大。
保持组件独立有很多好处"
- 重用功能(例如，web层使用服务层)
- 打包单个组件(例如，仅将API发送到客户端)
- 版本子组件;定义它们的版本依赖关系
你可以在一个大项目中做所有相同的事情，但很难确定哪些事情应该放在哪里，以及为什么要这样做。当这些界限明确时，生活就容易多了。
有多容易取决于项目，但是当您处理数十万行，有时是数百万行的代码时，将这些东西分解为节省了大量的头痛。
为什么选择在maven中创建一个单独的模块?来帮助你的发展。真的没有别的原因了。
您可能想要创建一个单独的模块的原因有很多:
- 关注点分离:是的，你可以在包中这样做，但如果它在一个单独的模块中，那么它可以单独编译，你可以减少包中的缠结[*]的数量。
- 模块由不同的团队管理，有自己的发布周期。
- 更容易理解的代码:如果你所有的dao代码在一个模块中，而你所有的web在另一个模块中，你可以分别测试它们。 模块可以是一个独立的可部署实体。我有一个项目，其中有两个web应用程序，5批次和其他两个核心模块(一个核心的web应用程序和一个核心的批次)。我现在可以分别构建和部署每个模块。
- 模块对外发布和使用。如果这是真的，那么你需要在这个模块中使用最少数量的'other'代码。
您选择分解为模块的原因与您选择分解为包的原因相同，但是在更高的层次上，在一组包中。
30似乎有些过分。但这可能是有充分理由的。这取决于你和你的项目来决定什么是合适的模块数量。
就我个人而言，我尽量不过度分割，除非有很好的理由这样做。
[*] Tangle:描述包之间链接的混乱。包A使用B, B使用C, C同时使用A和B，这对理解没有帮助
我认为过度模块化类似于过度工程。在我看来，最好的方法是从一个模块/项目开始，并一直坚持下去，直到每个人都清楚地意识到，这个现有模块的一部分将从提取到自己的模块中受益。是的，这意味着额外的工作，但对我来说，我宁愿做这些工作，而不是无休止地与不必要的复杂性作斗争，就我的构建和开发环境而言，为了从未真正实现的好处。
不幸的是，在项目开始时，甚至在编写一行代码之前，似乎有一种趋势，即模块化到第n度。
这样做还有另一个好处…如果我必须在"选定的"组件上部署，我不会浪费时间和资源来部署我不需要的依赖项。