一、项目模块定义
说明：一个产品分为各个独立的原子服务，通过这些独立的原子服务进行组合来满足各种业务的需求。
1、各原子服务关系与原则：
依赖关系：只能上级依赖下级，不可下级依赖上级；各模块之间不直接依赖，可以设置共享模块，给各模块进行依赖；
单一性原则：
原子服务之间：每个原子服务是独立的，假如生产中众多原子服务里，其中一个服务宕机了，而其他服务正常运行，则可以认为该服务是满足的单一原则；
各业务模块之间：每个业务模块之间不进行直接交叉依赖，分层可以按模块来，但该模块用到的代码只能都放在该模块的文件夹下，如果需要对其他模块提供接口，只能以接口的方式提供(provider)，如果是对外暴露的接口，则文件夹名一定取名为API，则没有歧义；
程序中的方法：原则为一个方法只干一件事，那么这个方法就不会臃肿，如果业务复杂，则可以先进行细分，然后一个方法对应一个细节；
仓储原则：即数据库持久化层，可单独建立一个模块，对外只是以接口的形式进行提供，这样可以做到整个持久化层可以单独下沉或分割，因为其他模块依赖的是接口，而不是具体哪一个持久化层类；
代码设计：在通常的代码设计中，由业务的角度来设计，决定技术的实现，而不是由技术来决定业务的原则；
代码细节：
循环尽量使用流式遍历(jdk8新特性)，如 xxxList.stream().map(xxx -> xxx).collect(Collectors.toList())
时间则采用jdk8提供的Instant类（如：Instant.now().toEpochMilli() ），该时间类没有并发问题；
谁使用谁销毁原则：即代码中的类使用的DTO、VO对象，一般只有自己类才能用到，则不用像PO对象一样单独创建一个实体类，只需要在该类下写一个私有的DTO、VO对象即可；
如静态常量，通常我们做项目会写一个公共的静态常量类，大家都习惯的只有用到常量就会在该类里添加，这是不对的，只有大家经常使用的、通用的才可添加，如具体类内部使用的，只需要在该使用类里进行添加抽象的静态常量即可；注意：工具类慎用，尽量用jdk或spring自带的工具类；
编写接口原则： 任何service接口，首先第一件事就是使用断言(spring自带)来进行参数校验，通常我们都会在前端和controller类里校验，但这是不够的，因为未来接口你是不知道有没有其他地方会进行调用，所以一定要添加断言；
使用IDE进行编码，页面一定不能出现黄色底，如果按鼠标单击黄色区域代码，左侧会有一个黄色小灯泡提示需要的优化；另外每一行的代码长度不能超过右侧的代码线，如超过了则进行换行；
类名和方法名取名不能随意，最好能直接通过英文名直接知道意思，另外注释不能缺，特别是有逻辑的地方，注释要全面；
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
