我刚才考虑过这个问题,最近我的商店正在制作它的第一个真正的Java网络应用程序.
作为介绍,我看到两个主要的包命名策略.(要清楚,我不是指整个'domain.company.project'的一部分,我在谈论它下面的包约定.)无论如何,我看到的包命名约定如下:
功能:根据业务领域,根据其功能在架构上命名您的包,而不是其身份. 另一个术语可能是根据'layer'命名.所以,你有一个*.ui包和一个*.domain包和一个*.orm包.您的包是水平切片而不是垂直切片.
这是多比逻辑命名更常见.事实上,我不相信我曾经见过或听说过这样做的项目.这当然让我很害羞(有点像认为你已经提出解决NP问题的方法),因为我不是非常聪明,我认为每个人都必须有充分的理由按照他们的方式去做.在另一方面,我不反对人们只是缺少在房间里的大象和我从来没有听说过的实际参数为做包命名这种方式.它似乎是事实上的标准.
逻辑:根据业务域标识命名您的包,并将与该垂直功能片有关的每个类放入该包中.
正如我之前提到的,我从未见过或听说过这一点,但这对我来说很有意义.
我倾向于垂直而不是水平地接近系统.我想进入并开发订单处理系统,而不是数据访问层.显然,我很有可能在该系统的开发中触及数据访问层,但重点是我不这么认为.当然,这意味着当我收到变更单或想要实现一些新功能时,不必为了找到所有相关的类而不必去一堆包中钓鱼.相反,我只是查看X包,因为我正在做的与X有关.
从开发的角度来看,我认为让您的软件包记录您的业务领域而不是您的架构是一项重大胜利.我觉得这个领域几乎总是系统的一部分,因为系统的体系结构,特别是在这一点上,它的实现几乎变得平凡,因此很难理解.事实上,我可以通过这种类型的命名约定进入系统,并立即从包的命名知道它处理订单,客户,企业,产品等,这似乎非常方便.
看起来这样可以让你更好地利用Java的访问修饰符.这使您可以更清晰地将接口定义到子系统中,而不是定义到系统的各个层中.因此,如果你有一个你想要透明持久的订单子系统,理论上你永远不会让任何其他东西知道它是持久的,因为不必在dao层中为其持久性类创建公共接口,而是将dao类包装在只有它处理的类.显然,如果您想公开此功能,可以为其提供界面或将其公开.通过将系统功能的垂直切片分成多个包,您似乎失去了很多.
我认为我可以看到的一个缺点是,它确实使得剥离层更加困难.您必须进入并更改所有软件包中的所有类,而不是仅删除或重命名软件包,然后使用备用技术删除新软件包.但是,我不认为这是一个大问题.这可能源于缺乏经验,但我必须想象,与您进入和编辑系统中的垂直特征切片的次数相比,您更换技术的次数相形见绌.
所以我想那个问题会告诉你,你如何命名你的包裹以及为什么？请理解我并不一定认为我偶然发现了金鹅或其他东西.我对这一切都很陌生,主要是学术经验.但是,我无法发现我的推理中的漏洞,所以我希望你们都能这样,以便继续前进.
对于包装设计,我首先按层,然后通过一些其他功能.
还有一些额外的规则:
层从最一般(底部)到最具体(顶部)堆叠
每一层都有一个公共接口(抽象)
一层只能依赖于另一层的公共接口(封装)
一个图层只能依赖于更一般的图层(从上到下的依赖关系)
层优选地取决于其正下方的层
因此,对于Web应用程序,您可以在应用程序层中具有以下层(从上到下):
表示层:生成将在客户端层中显示的UI
应用程序层:包含特定于应用程序的逻辑,有状态
服务层:按域分组功能,无状态
集成层:提供对后端层的访问(db,jms,email,...)
对于生成的包布局,这些是一些额外的规则:
每个包名的根是
层的界面进一步按功能划分:
图层的私有实现以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.
当您使用垂直方法进行包装设计时,即首先按功能划分,然后强制所有具有不同功能级别的构建块进入相同的"功能夹克".您可以为更具体的模块设计通用模块.但是这违反了更普遍的层不应该知道更具体的层的重要原则.例如,服务层不应该在应用层的概念之后建模.
我发现自己坚持使用鲍勃叔叔的包装设计原则.简而言之,要一起重用和一起更改的类(出于同样的原因,例如依赖项更改或框架更改)应该放在同一个包中.IMO,功能分解比大多数应用程序中的垂直/业务特定分解更有可能实现这些目标.
例如,域对象的水平切片可以由不同类型的前端甚至应用程序重用,并且当需要更改底层Web框架时,Web前端的水平切片可能会一起更改.另一方面,如果跨不同功能区域的类被分组在这些包中,很容易想象这些更改在许多包中产生的连锁反应.
显然,并非所有类型的软件都是相同的,并且在某些项目中,垂直细分可能是有意义的(在实现可重用性和可接近变化的目标方面).
通常存在两种级别的划分.从顶部开始,有部署单元.这些被命名为"逻辑"(在您的术语中,认为Eclipse功能).在部署单元内部,您可以对软件包进行功能划分(想想Eclipse插件).
例如,特征是com.feature,它包括com.feature.client,com.feature.core和com.feature.ui插件.在插件内部,我对其他软件包的分工很少,尽管这也不常见.
更新:顺便说一下,Juergen Hoeller就InfoQ上的代码组织发表了很好的演讲:http://www.infoq.com/presentations/code-organization-large-projects.Juergen是Spring的架构师之一,对这些东西了如指掌.
京公网安备 11010802040832号 | 京ICP备19059560号-6 