从源码中学习包的命名
背景
在日常开发中，我们通常不会将全部代码，写在一个文件夹或一个类文件中。如果这样，文件结构很混乱，且代码可读性非常差，也不容易定位和查找类文件。
根据单一职责原则，更好的额做法是，我们根据代码的职责，将其划分为各个不同的模块、文件夹和类文件。这样，后期阅读和维护起来，会比较高效。
一些包命名的建议
那应该如何定义好文件结构呢？这里根据源码经验，简单给出一些可参考的，包命名推荐：
- controller：一般用作暴露给前端的接口类，不做业务处理，只是接口的入口；
- domain：实体类，业务根据需要细分为vo/dto/po等；
- service：服务接口层（interface）,一般只定义业务接口，不做实现；需要做好注释；
- impl：服务的接口实现类（interface实现），一般用来处理具体的接口逻辑；
- mapper/dao：持久层，一般直接与SQL执行有关；处理SQL的ORM映射关系等；
- common：一些与业务无关的公用代码，比如统一的返回结果，全局的工具类等；其下可以根据职责再拆成多个小包；
- utils：工具类，一些业务无关的，可复用的工具类；
- exception：存放自定义异常类，与系统异常区分；
- constant：存放常量类；为了避免在代码中，使用魔法值，可以将常量抽取出常量类，方便维护和复用；
- annotation：存放自定义注解，有时需要基于AOP进行业务增强时，可能需要自定义注解；
-
config：存放一些配置类，往往在配置类中映射配置文件，并注入Bean容器等；
-
filter / interceptor：定义一些过滤器、拦截器等；
-
cache：定义缓存相关的一些类文件；
-
enum：存放一些通用的枚举类等；
-
schedule/job：存放一些和定时任务执行相关的类；
-
biz / facade：存放一些门面模式的方法类；一些逻辑较复杂的服务类，通过门面模式，再去调用具体的Service类；
