原创：猿逻辑，欢迎分享，转载请保留出处。跟着小q学Java，最快的进阶方式。
很多同学创建一个项目之后，就迫不及待的上手开写了。项目代码不像一些框架代码一样写的随意，但一般都是采用MVC的模式进行开发。
清晰的目录结构，能够辅助其他同学轻而易举的了解项目的功能模块，在项目中保持整体一致的约定也是一个非常好的习惯。
有两种典型的分类方式，但也有很多细节。
根据分层进行设计
这种模式是我们常见的根据MVC的基础概念进行分层的。
- Model（模型）表示应用程序核心（比如数据库记录字段）。
- View（视图）显示数据（数据库记录）。
- Controller（控制器）处理输入（写入数据库记录）。
在项目划分上，就类似下面的目录结构。
模型
domain目录下面，放的就是项目的模型层。在实际操作中，它还可能有下面几种名字，在普通项目中区别不大，你最好在项目中保持相同的意义来避免歧义。
entity这个意义比较明显，就是实体的意思，最常用model模型的意思，一般用来在不同系统之间交互。但如果你的模型非常简单，直接用entity来表示也是可以的domain这个范围有点大，在许多国外项目中经常使用。这个是表达意义上的差异，和model其实是差不多的。在DDD的场景中意义要更大一些。
由于model和domain的范围是比较大的，我通常在项目中使用entity来表示和数据库的交互。在JPA之类的ORM中，也是做相关处理的。比如javax.persistence.Entity注解。
Dao
dao层叫数据访问层,全称为data access object，属于一种比较底层，比较基础的操作。在一些其他框架中，还会叫别的名字。
mapper这个一般是Mybaits之类的框架所生成的目录，通常是一些接口。repository仓库的意思，在jpa中经常用。
Dao应该满足最小封装原则，理论上只涉及一句SQL的执行。如果有多个数据的存取动作，需要封装在Service中，并用事务进行管理。
service和controller
这个没什么好说的，基本上所有重要的逻辑都在这里完成。service用于逻辑处理，controller用于接口暴露。
根据功能组织
大多数情况下，我们使用上面的这种划分模式，能够很好的完成工作。比如，所有的数据处理，都放在Dao层，所有的逻辑处理，都放在Service层。
这在小项目中相安无事，但如果项目中，有成百上千个Entity，这些目录中的文件就会爆炸，以至于最后无法维护。
另外一个问题就是，仅仅一个简单的功能，就可能分散在多个package下的多个文件中，大型项目维护变得困难。
我们有另外一个思路，就是根据功能进行分组。比如下面的截图。
我们把相似功能，放在modules下的单个文件夹中。如果这个功能模块比较大，我么可以在功能模块下，再进行分层设计。
比如上图，有一个商品服务，我们单独给它分配了一个目录空间goods，然后在里面又划分了dao、entity等目录；但对于Service喝Controller，我们简单的放在了外层，可以看到在模块内的分配是比较灵活的。
这么做的好处是显而易见的。功能变的非常的集中，各个package之间的内容互不影响。
更妙的是，项目初期我可以使用这种组织方式，把所有的功能放在一个项目中。到了项目的瓶颈期，想要做一些优化的时候，比如要做一些微服务拆分，服务拆分等。这时候我们就可以快速的，将服务拆分出去，比如拆分出一个专门的图片服务。
小结
综上所述，小Q认为，单纯的使用分层的package，并不是一个好的习惯。
你可能对这种后台管理类的项目驾轻就熟，有很多有用的模版，仅仅遵循这些分层的简单规律。这应付一些外包项目，干一些一锤子买卖的时活，或许没什么问题，但一旦是比较大的长期项目，这种分层的目录接口就显现出它的弊端。
因为随着访问量的增加，还有低耦合高内聚的需求增加，扩展性将会是制约项目发展的最主要因素。
很多人都假装颓废，我劝你不要上当。不要放弃每一个想要学习的念头，因为那可能是未来的你在向你求救。我是小Q，与你共进步。放弃不难，但坚持一定很酷。
