java项目中包的命名_你在Java项目中为包命名使用什么策略？为什么？

对于封装设计，我先分层，然后通过一些其他功能。

还有一些额外的规则：

>层从最普通(底部)到最特定(顶部)

>每一层都有一个公共接口(抽象)

>一个层只能依赖于另一层的公共接口(封装)

>一个层只能依赖于更一般的层(依赖性从上到下)

>层优选取决于其正下方的层

因此，对于Web应用程序，例如，您可以在应用程序层中(从上到下)有以下层：

>表示层：生成将显示在客户端层中的UI

>应用层：包含特定于应用程序的有状态的逻辑

>服务层：按域分组功能，无状态

>集成层：提供对后端层(db，jms，email，…)的访问。

对于生成的包布局，这些是一些额外的规则：

>每个包名称的根是< 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。

当您使用垂直方法进行包装设计时，即先按功能划分，然后将具有不同功能级别的所有构建块强制放入同一个“功能外套”中。您可以为更具体的模块设计一般模块。但这违反了更一般的层不应该知道更多特定层的重要原则。例如，不应该在应用层的概念之后对服务层进行建模。