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