Java 为什么在包上使用许多子项目和依赖项？

在我的职业生涯中，我主要从事中小型java项目。我最近在eclipse中看到了一个由30个项目组成的大型项目。我并不真正理解创建许多小项目然后维护项目间依赖关系的概念。什么时候我们更喜欢这种方式而不是简单地把东西打包

我猜这是一个专业的东西（主要是使用Ant）。我也在阅读Maven的模块概念——我在网上看到一些链接，建议在父模块下为web、dao和服务层创建不同的模块。这真的是一种常见/最佳实践吗

---

有或没有maven——这样的划分真的让生活更轻松吗？将所有内容放在一个项目中，并为不同的层定义良好的包结构，不是更紧凑吗？

我认为过度模块化类似于过度工程化。在我看来，最好的方法是从一个模块/项目开始，并一直坚持下去，直到所有相关人员都清楚地看到，现有模块的一部分将从提取到自己的模块中获益。是的，这意味着在这一点上需要额外的工作，但对我来说，我宁愿在那时做这项工作，也不愿在构建和开发环境方面与不必要的复杂性进行无休止的斗争，以获得从未真正实现的好处

---

不幸的是，在一个项目开始时，似乎有一种趋势，就是在编写一行代码之前，就将项目模块化到第n级。

在需要时，通常会将项目拆分为API、实现、web等组件。大型项目就是这么大

将组件分开有很多好处”

• 重用功能（例如，web层使用服务层
• 打包单个组件（例如，将API发送给客户）
• 版本子组件；定义其版本依赖关系

你可以在一个巨大的项目中做所有相同的事情，但是要确定什么去了哪里，为什么去，就更困难了。当这些界限被清楚地定义时，生活就更容易了

---

有多容易取决于项目，但是当你处理数十万行代码，有时是数百万行代码时，分解这些代码可以节省大量的麻烦。

为什么选择在maven中创建一个单独的模块？以帮助你进行开发。真的没有其他原因

您可能希望创建单独模块的原因有很多：

关注点分离：是的，您可以对包执行此操作，但如果它位于单独的模块中，则可以单独编译，并且可以减少包中的混乱[*]

这些模块由不同的团队管理，有自己的发布周期

更容易理解的代码：如果您的所有dao代码都在一个模块中，而您的所有web都在另一个模块中，那么您可以单独测试它们

一个模块可以是一个单独的可部署实体。我有一个项目，其中有两个web应用程序、5个批处理和两个其他核心模块（一个核心用于web应用程序，一个核心用于批处理）。我现在可以分别构建和部署每个模块

这些模块是在外部发布和使用的。如果这是真的，那么您希望此模块中的“其他”代码的最小数量

您选择拆分为模块的原因与拆分为包的原因相同，但在更高的级别，在一组包中

30似乎太多了。但这可能有很好的理由。这取决于你和你的项目来决定模块数量的正确级别

就我个人而言，我尽量不过度分裂，除非有很好的理由这样做

---

[*]Tangle:mess，它描述了包之间的链接。包A使用B，它使用C，它同时使用A和B。这一点无助于理解。

这还有另一个好处。如果我必须在“选定”组件上部署，我就不会浪费时间和资源部署我不需要的依赖项。

大多数“企业”"然而，y项目在一开始就有非常明确的模块分离。+1：模块有助于防止对某些web库的依赖关系蔓延到底层。只有当出现问题时，你才会注意到这一点，突然之间，这将是一个巨大的痛苦，但要解决它。实际上，大多数构建系统都可以做到这一点，所以这并不是一个真正的原因。但是如果如果你这样做了，那么你会发现一些构建系统比其他构建系统做得更好。+1表示“可以单独编译”。#2和#3也适用于包。