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