不久前我就想到了这个问题，最近它又出现了，因为我的商店正在开发它的第一个真正的 Java Web 应用程序。
作为介绍，我看到了两种主要的包命名策略。（需要明确的是，我不是指整个 'domain.company.project' 部分，我指的是下面的包约定。）无论如何，我看到的包命名约定如下：
功能性：根据架构上的功能而不是根据业务领域的身份来命名您的包。 另一个术语可能是根据“层”命名。因此，您将拥有一个 *.ui 包、一个 *.domain 包和一个 *.orm 包。您的包裹是水平切片而不是垂直切片。
这比逻辑命名更常见。事实上，我相信我从未见过或听说过这样做的项目。这当然让我怀疑（有点像认为你已经想出了一个解决 NP 问题的方法），因为我不是很聪明，而且我认为每个人都必须有充分的理由这样做。另一方面，我并不反对人们只是想念房间里的大象，而且我从未听说过以这种方式命名包的实际论据。这似乎是事实上的标准。
逻辑：根据业务域标识命名您的包，并将与该垂直功能切片有关的每个类放入该包中。
正如我之前提到的，我从未见过或听说过这一点，但这对我来说很有意义。
我倾向于垂直而不是水平地接近系统。我想进去开发订单处理系统，而不是数据访问层。显然，我很有可能会在该系统的开发中触及数据访问层，但关键是我不这么认为。当然，这意味着当我收到变更单或想要实现一些新功能时，不必为了找到所有相关的类而在一堆包中四处寻找会很好。相反，我只是查看 X 包，因为我所做的与 X 有关。
从开发的角度来看，我认为让你的包记录你的业务领域而不是你的架构是一个重大的胜利。我觉得域几乎总是系统中更难理解的部分，因为系统的架构，特别是在这一点上，在其实现中几乎变得平凡。事实上，我可以使用这种类型的命名约定并立即从包的命名中知道它处理订单、客户、企业、产品等的系统，这似乎非常方便。
看起来这样可以让您更好地利用 Java 的访问修饰符。这使您可以更清晰地将接口定义到子系统中，而不是系统的层中。因此，如果您有一个希望透明持久化的订单子系统，理论上您可以通过不必在 dao 层中为其持久性类创建公共接口，而是将 dao 类包装在只有它处理的类。显然，如果您想公开此功能，您可以为其提供一个接口或将其公开。通过将系统功能的垂直部分拆分到多个包中，您似乎失去了很多。
我想我可以看到的一个缺点是它确实使剥离图层变得更加困难。而不是仅仅删除或重命名一个包，然后用另一种技术将一个新的包放到适当的位置，您必须进入并更改所有包中的所有类。但是，我认为这没什么大不了的。这可能是由于缺乏经验，但我不得不想象，与您在系统中进入和编辑垂直特征切片的次数相比，您更换技术的次数相形见绌。
所以我想这个问题会问你，你如何命名你的包，为什么？请理解，我不一定认为我在这里偶然发现了金鹅或其他东西。我对这一切都很陌生，主要是学术经验。但是，我无法发现我的推理中的漏洞，所以我希望你们都可以，这样我就可以继续前进。