不久之前，我在这里看到一个有关Java包的细粒度组织的问题。例如，my.project.util, my.project.factory, my.project.service等。
在Java中，有哪些关于包组织和其中内容的最佳实践?
在Java项目中，您如何组织类？
例如，我正在与几个人合作的项目中有一个名为beans的包。它最初是一个包含简单bean的项目，但由于经验不足和时间不足，它最终包含了几乎所有东西。我通过将一些工厂类放入工厂包（具有创建bean的静态方法的类）来对其进行了一些清理，但我们还有其他执行业务逻辑和从属性文件检索代码消息等简单处理（没有业务逻辑）的类。
beansfactoriescollectionsordersstorereportsorders包中，以便隐藏有关如何创建订单的详细信息。包的组织和结构通常是一个热门话题，以下是一些简单的指南，用于包命名和组织结构：
com.company.product.moduleacom.company.product.module.web 或 com.company.product.module.util 等。com.company.product.model 和 com.company.product.util 等。经过几次实验和尝试，你应该能够找到一种适合自己的结构。不要固守一种惯例，保持开放心态。
简短回答：每个模块/特性一个包，可能带有子包。将密切相关的事物放在同一个包中。避免包之间的循环依赖。
详细回答：我同意这篇文章的大部分观点
我更喜欢将特性放在前面，但这取决于您的项目。请考虑以下要素：
示例：
com/company/module
+ feature1/
- MainClass // The entry point for exploring
+ api/ // Public interface, used by other features
+ domain/
- AggregateRoot
+ api/ // Internal API, complements the public, used by web
+ impl/
+ persistence/
+ web/ // Presentation layer
+ services/ // Rest or other remote API
+ support/
+ feature2/
+ support/ // Any support or utils used by more than on feature
+ io
+ config
+ persistence
+ web
这只是一个示例，比较正式。例如它为feature1定义了两个接口。通常不需要这样做，但如果被不同人以不同的方式使用，这可能是一个好主意。您可以让内部API扩展公共API。
我不喜欢'impl'或'support'这些名称，但它们有助于将不那么重要的内容（领域和API）与重要的内容分开。在命名方面，我喜欢尽可能具体。如果您有一个名为“utils”的包含20个类的包，请将StringUtils移到support/string、HttpUtil移到support/http等。
我看到一些人推崇“按功能打包”而不是“按层次打包”，但是我多年来使用了很多方法，发现“按层次打包”比“按功能打包”要好得多。
此外，我发现一个混合策略：按模块、层次和功能打包的策略在实践中非常有效，因为它具有许多“按功能打包”的优点：
我在这里详细解释：Java Package Name Structure and Organization，但我的标准包结构是：
revdomain.moduleType.moduleName.layer.[layerImpl].feature.subfeatureN.subfeatureN+1...
其中：
revdomain 反转的域名，例如com.mycompany
moduleType [应用程序*|框架|工具]
moduleName，例如，如果模块类型是应用程序，则为myAppName，如果是会计框架，则为'finance'
layer [模型|用户界面|持久化|安全等等]
layerImpl，例如wicket、jsp、jpa、jdo、hibernate（注意：如果层是模型，则不使用）
feature，例如，财务
subfeatureN，例如，会计
subfeatureN+1，例如，折旧
*有时，如果moduleType是应用程序，则省略'app'，但将其放入其中可以使所有模块类型的包结构保持一致。