您在Java项目中使用什么策略来命名包？为什么？

我在一段时间前就想到了这一点，最近当我的商店正在开发第一款真正的Java web应用程序时，它又重新出现了

作为介绍，我看到了两种主要的包命名策略。（要清楚，我不是指整个“domain.company.project”部分，我指的是下面的包约定。）总之，我看到的包命名约定如下：

功能性：根据软件包的体系结构功能来命名软件包，而不是根据业务域来命名软件包。另一个术语可能是根据“层”命名。因此，您将有一个*.ui包、一个*.domain包和一个*.orm包。您的包是水平切片而不是垂直切片

这比逻辑命名更常见。事实上，我相信我从未见过或听说过这样的项目。这当然让我产生了怀疑（有点像认为你已经想出了一个NP问题的解决方案），因为我不是非常聪明，我认为每个人都有很好的理由这样做。另一方面，我并不反对人们忽略房间里的大象，我从来没有听到过这样命名软件包的真正理由。这似乎是事实上的标准

逻辑：根据包的业务域标识对包进行命名，并将与该功能垂直部分相关的每个类放入该包中

正如我之前提到的，我从未见过或听说过这一点，但这对我来说意义重大

我倾向于垂直而不是水平地接近系统。我想开发订单处理系统，而不是数据访问层。显然，在开发该系统时，我很有可能会触及数据访问层，但问题是我不这么认为。当然，这意味着当我收到变更单或想要实现一些新特性时，最好不要为了找到所有相关的类而在一堆包中四处搜索。相反，我只是查看X包，因为我所做的与X有关

从开发的角度来看，我认为让您的包记录您的业务领域而不是体系结构是一个重大的胜利。我觉得域几乎总是系统中难以探索的部分，因为系统的体系结构，尤其是在这一点上，在其实现中几乎变得平淡无奇。事实上，我可以使用这种类型的命名约定来访问一个系统，并立即从包的命名中知道它处理订单、客户、企业、产品等，这似乎非常方便

这似乎可以让您更好地利用Java的访问修饰符。这允许您更清晰地将接口定义到子系统中，而不是系统的各个层中。因此，如果您有一个希望透明持久化的orders子系统，理论上，您可以不必在dao层中为其持久化类创建公共接口，而只使用它所处理的类来打包dao类，从而永远不让其他任何东西知道它是持久化的。显然，如果您想公开此功能，可以为其提供接口或将其公开。通过将系统功能的垂直部分拆分到多个包中，您似乎损失了很多

我想我能看到的一个缺点是，它确实使剥离层变得有点困难。不要只是删除或重命名一个包，然后用另一种技术删除一个新包，你必须进入并更改所有包中的所有类。然而，我不认为这有什么大不了的。这可能是因为缺乏经验，但我不得不想象，与您在系统中插入和编辑垂直特征切片的次数相比，您交换技术的次数相形见绌

---

因此，我想问题会摆在你面前，你如何命名你的包裹，为什么？请理解，我不一定认为我在这里偶然发现了金鹅或其他东西。我对这一切都很陌生，大部分是学术经验。然而，我无法发现我推理中的漏洞，所以我希望你们都能发现，这样我就可以继续了。

这取决于逻辑过程的粒度

如果它们是独立的，您通常会在源代码管理中为它们创建一个新项目，而不是一个新包

我目前正在进行的项目正朝着逻辑拆分的方向发展，有一个用于jython方面的包，一个用于规则引擎的包，一个用于foo、bar、binglewozzle等的包。我正在考虑为该包中的每个模块提供特定于XML的解析器/编写器，而不是一个XML包（我以前已经做过），尽管仍然会有一个核心XML包，其中包含共享逻辑。然而，这样做的一个原因是，它可能是可扩展的（插件），因此每个插件还需要定义其XML（或数据库等）代码，因此将其集中化可能会在以后引入问题

最后，这似乎是对特定项目最合理的方式。然而，我认为按照典型的项目分层图进行打包是很容易的。最终，您将得到逻辑和功能组合的包装

需要的是标记名称空间。某些Jython功能的XML解析器可以同时标记Jython和XML，而不必选择其中之一

---

或者可能我正在wibbling。

我处理过的大多数java项目都是先从功能上切片java包，然后从逻辑上切片

通常零件都足够大，以至于它们被分解成许多块

com.company.appname.presentation.internal
com.company.appname.presentation.springmvc.product
com.company.appname.presentation.servlet
...

com.company.appname.application.lookupproduct
com.company.appname.application.internal.lookupproduct
com.company.appname.application.editclient
com.company.appname.application.internal.editclient
...

com.company.appname.service.clientservice
com.company.appname.service.internal.jmsclientservice
com.company.appname.service.internal.xmlclientservice
com.company.appname.service.productservice
...

com.company.appname.integration.jmsgateway
com.company.appname.integration.internal.mqjmsgateway
com.company.appname.integration.productdao
com.company.appname.integration.internal.dbproductdao
com.company.appname.integration.internal.mockproductdao
...