关于项目内包模块的命名方式

[findshine]

例一个大项目，分若干大模块8个左右，业务场景比较独立也比较典型

那么在命名一般采用哪种呢？

方案1：

com.xx.controller
a模块Controller.java //a模块 Controller
b模块Controller.java //b模块 Controller
c模块Controller.java //c模块 Controller
d模块Controller.java //d模块 Controller
...

com.xx.service
a模块service.java //a模块 service
b模块servicejava //b模块 service
c模块servicejava //c模块 service
d模块service.java //d模块 service
...
com.xx.impl
a模块impl. java //a模块 impl
b模块impl. java //b模块 impl
c模块impl. java //c模块 impl
d模块impl. java //d模块 impl


...


还是方案2

com.xx.a
aContoller.java
aService.java
aImpl.java
...

com.xx.b
bContoller.java
bService.java
bImpl.java
...

com.xx.c
cContoller.java
cService.java
cImpl.java
...

-----------------------
一种是基于层来 一种是基于业务来，请问哪种适用

[pilnyun335857183]

先基于业务再分层的做法比较清晰，个人意见

[爱摸鱼de老邪]

个人觉得方案2好点。

[oO临时工Oo]

想当年我也纠结这样的问题。 就你所提的问题，一般来讲：小软件系统用第一种方案、复杂一点的软件系统用第二种方案； 分工程 分包是一种方案，分工程（Project）也是一种方案。 子系统 如果系统很复杂就应该分子系统，子系统一般运行在不同的物理机上（当然理论上可能运行在同一台物理机），各子系统通过上层架构进行整合。那么这样一来，各子系统可能又是一个业务比较单一的系统，就不会涉及类似分包都不知道怎么分的情况了。例如，就淘宝这样的系统，购物车服务器估计就不少，其实这些服务器上做的业务相对单一，但这样的工作量是很大的。

[皮卡皮卡屁卡丘]

个人觉得方案2好一点。

[maradona1984]

方案三,方案1和方案2的结合体 包名需要体现分层,也得体现模块.大模块不要只用一个controller,service,拆分更细粒度点,这样你每个包里类不会过多也不会过少,每个类里代码数不会太多 个人观点:写代码的时候要简单,最直观的简单是代码少,如何做到代码少(看起来代码少)就是业务隔离,合适拆分,才能保证别人修改代码时能接触到较少代码