您在 Java 项目中使用什么策略进行包命名？为什么？ [关闭]

我不久前就想过这个问题，最近当我的商店正在开发第一个真正的 Java Web 应用程序时，这个问题又重新出现了。

作为介绍，我看到两个主要的包命名策略。 （需要明确的是，我并不是指其中的整个“domain.company.project”部分，而是指其下面的包约定。）无论如何，我看到的包命名约定如下：

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

   This is much比逻辑命名更常见。事实上，我认为我从未见过或听说过这样做的项目。这当然让我感到怀疑（有点像认为你已经想出了一个 NP 问题的解决方案），因为我不是很聪明，而且我认为每个人都必须有充分的理由这样做。另一方面，我并不反对人们只是错过了房间里的大象and我从未听过真正的争论for以这种方式进行包命名。这似乎只是事实上的标准。

2. 逻辑：根据业务域身份命名您的包并将与垂直功能部分相关的每个类放入该包中。

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

   1. 我倾向于垂直而不是水平地处理系统。我想开发订单处理系统，而不是数据访问层。显然，我很有可能在该系统的开发过程中接触数据访问层，但重点是我不这么认为。当然，这意味着当我收到变更订单或想要实现一些新功能时，最好不必在一堆包中寻找所有相关的类。相反，我只是查看 X 包，因为我所做的事情与 X 有关。

   2. 从开发的角度来看，我认为让你的包记录你的业务领域而不是你的架构是一个重大胜利。我觉得域几乎总是系统中更难理解的部分，因为系统的架构，特别是在这一点上，在其实现中几乎变得平凡。事实上，我可以进入具有这种命名约定的系统，并立即从包的命名中知道它处理订单、客户、企业、产品等，这似乎非常方便。

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

   4. 我想我能看到的一个缺点是它确实使剥离图层变得更加困难。您必须进入并更改所有包中的所有类，而不是仅仅删除或重命名包，然后使用替代技术放置一个新包。不过，我不认为这有什么大不了的。这可能是由于缺乏经验，但我必须想象，与您进入并编辑系统中的垂直功能切片的次数相比，您更换技术的次数相形见绌。

所以我想你会遇到这样的问题：你如何命名你的包以及为什么？请理解，我不一定认为我在这里偶然发现了金鹅之类的东西。我对这一切都很陌生，主要是学术经验。然而，我无法发现我的推理中的漏洞，所以我希望你们都能找到，以便我可以继续前进。

对于包装设计，我首先按层划分，然后按其他一些功能划分。

还有一些附加规则：

1. 层从最一般（底部）到最具体（顶部）堆叠
2. 每层都有一个公共接口（抽象）
3. 一层只能依赖于另一层的公共接口（封装）
4. 一个层只能依赖于更通用的层（从上到下的依赖）
5. 一个层最好依赖于它正下方的层

因此，以 Web 应用程序为例，您的应用程序层中可以有以下层（从上到下）：

• 表示层：生成将在客户端层显示的 UI
• 应用层：包含特定于应用程序的逻辑，有状态
• 服务层：按域对功能进行分组，无状态
• 集成层：提供对后端层（db、jms、电子邮件等）的访问

对于最终的包布局，有一些附加规则：

• 每个包名称的根是<prefix.company>.<appname>.<layer>
• 层的接口按功能进一步划分：<root>.<logic>
• 层的私有实现以 private 为前缀：<root>.private

这是一个布局示例。

表示层按视图技术划分，也可以选择按应用程序（组）划分。

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
...

像这样分离包的优点是更容易管理复杂性，并且提高了可测试性和可重用性。虽然这看起来像是很多开销，但根据我的经验，它实际上非常自然，每个从事此结构（或类似结构）工作的人都会在几天内学会它。

为什么我认为垂直方法不太好？

在分层模型中，多个不同的高层模块可以使用同一个低层模块。例如：可以为同一个应用程序构建多个视图，多个应用程序可以使用同一个服务，多个服务可以使用同一个网关。这里的技巧是，当穿过各层时，功能级别会发生变化。更具体层中的模块不会将 1-1 映射到更一般层中的模块，因为它们表达的功能级别不会映射 1-1。

当您使用垂直方法进行封装设计时，即首先按功能划分，然后强制所有构建块具有不同的功能levels的功能融入到同一个“功能夹克”中。您可以为更具体的模块设计通用模块。但这违反了更一般的层不应该了解更具体的层的重要原则。例如，服务层不应按照应用程序层的概念进行建模。