关于工程项目的目录划分的问题总结

一、基本的划分方式
按照功能模块划分；
按照业务模块划分；
按照maven项目分模块划分；
二、各个划分方式的适用情况
模块划分，还是层级划分，要考虑一些客观情况，如下: 

1、如果涉及大型项目团队协作开发，建议按业务模块划分

因为业务模块之间的耦合性相对于层级的耦合性要低，这样程序员在开发模块时，基本上要开发action层，service层，dao层和model层（其中action处理请求的接收和页面的跳转，service负责业务逻辑处理，dao层负责数据持久化处理，model放置的是实体类，数据类等）；
这样开发的接触面比较全，而且基本上不需要与其它模块进行交互，减少沟通交流时间，能提高开发效率。如果按照层级划分，那么多人开发时，会存在action依赖service，而service由别人开发，会涉及到交流、沟通（如：action需要的业务方法，需要先告诉service开发人员等等若干情况）；
当然这样就涉及到部分代码重复的情况，那么公共服务接口应该只是保留一份，放在base包里面。比如a,b模块有相同的实体类，可提取到base包中，方便其他功能模块共用，比如一些父类也将抽取放置到base中，这样的划分对于每个功能模块的修改都可以做到独立，方便团队的开发，每个开发人员只需要针对自己的功能模块进行修改。对于以后增加功能模块也比较方便。也就是说在功能模块之外，应该还有公共基础模块，那些filter和util等公共部分就放在这里；
还要看看未来的部署方式。如果是准备模块独立部署，则模块为大。绝大部分目前都是模块为大，再分层。这样也符合分而治之的思路。

2、如果独立开发，模块单一，只要结构清晰，后期维护方便，怎么划分都可以，即可以按照功能模块划分

（1）首先该方法适合小型，模块单一的项目，开发效率高，适用于对类的抽取与重用，但是不适合大型项目对模块的抽取，否者在一个项目中有非常多的package，不易对项目进行管理和维护；
（2）一个架构的雏形：先按照各个层来区分 就是典型的MVC 三层


先创建好：
controller          service          model 

然后在创建你需要的工具类：common               filter            interceptor 

最后根据你的模块 去扩充 
controller.XXX功能 
service.XXX功能 
model 可以把model 统一

3、以maven为架构的拆分方法 
（1）此方法对第一种方法作了改善，但不利于项目的维护和管理。此方法就是建立三个maven工程项目，将每个项目测试，编译，打包到maven库中，当依赖方需要依赖该模块时，该模块对应的项目在maven仓库中的坐标配置在依赖放的pom.xml中，这样虽然不能彻底解决依赖问题，但是可以极大程度的降低依赖。
（2）一般情况下，稍微大点的工程，需要把模块进行拆分子工程，就是另外再生成一个模块，然后按照功能模块划分的方式，工程之间进行依赖 若是不想划分子模块工程的话，按照业务模块划分的方式稍微更加合理点。

总结：这个都不一定，主要是具体需求情况而定，而且看当初搭建架构的时候进行约定以及后期部署的情况等等多方面考虑。