IntelliJ IDEA项目模块与Java 9模块是否有不同的概念？

Question

我从没在IntelliJ IDEA中使用过模块，但在Java 9中出现过模块（我也从未使用过，但现在想研究一下这是什么）

所以问题是：彼此匹配吗？还是IDEA模块出现在很久之前并出于不同目的？

Answer 1

这是一个类似的概念，早在Java 9模块出现之前。它也不是特定于IDE的。当处理包含多个子项目的项目时，Maven和Gradle之类的构建系统也使用此概念。在IntelliJ IDEA术语中，该模块只是一个子项目（在Eclipse中，该模块是一个Project，而Workspace可以具有多个项目）。

Java 9模块映射到IntelliJ IDEA模块，并通过指定以下内容的模块描述符提供附加功能：

• 它显式提供给其他模块的软件包（所有 模块中的其他软件包对于其他对象是隐式不可用的 模块）
• 它提供的服务
• 消费的服务
• 它还可以反射其他哪些模块

  

IntelliJ IDEA已经具有项目模块的概念。每一个   IntelliJ IDEA模块构建自己的类路径。随着介绍   在新的Java平台模块系统中，IntelliJ IDEA模块必须   通过支持Java平台的模块路径来扩展其功能   如果使用它代替类路径。

相关链接：

• IntelliJ IDEA modules explained
• Migrating From Eclipse to IntelliJ IDEA
• Understanding Java 9 Modules
• Getting Started with Java 9 Module System
• Support for Java 9 Modules in IntelliJ IDEA

Answer 2

就像我喜欢Intellij一样，我必须回答是：有一个很大的不同。

Java 9模块是实现封装和解耦的非常必要的步骤。但是，由于Intellij模块在单个Intellij（因此也就是VCS）项目中的成员身份，因此在Intellij模块中存在一种（偶然的？病理的？）耦合形式。 Java 9模块可以（也许应该从封装的角度来看）在单独的VCS / IDE项目中开发，从中仅可以公开有意义的API。 super (parent) POM是一种提供跨项目的非病理耦合以减少冗余的机制。

基于良好定义的域和有界上下文的模块应该可以免费重用：这是我们多年来一直在讨论的组件化迈出的一大步。这些域不是随机的-它们反映了对世界的新兴分析。如果听起来像我在提倡anarchy and Balkanization faced by Node developers之类的东西-我不是：经过充分分析的领域是关键。

要么Intellij模块从“本来就很不错的引擎盖下耦合”中“受益匪浅”，这是Intellij项目的巨大好处之一，或者通过将它们维护在单个项目中没有任何增值。在非TBD环境中工作，每张JIRA机票都有分支机构，这增加了这种耦合（个人经验）的成本。

此耦合的另一个答案的理由是可能涉及对多个模块的更改的“重构”。但这是代码/设计的味道：对公共API进行重大更改，这对所有客户都是一个问题，通常可以通过一些想象力，弃用，EOL-警告（{{ 3}}）等，或者这些模块表现出病理上的凝聚力，这可能是由于对有限上下文的分析不完整所致。