1.鼓励使用java8的函数式进行开发，主意其不变性特性。java
说明：函数式开发在多核服务器上运行效率跟核数呈正相关，而传统java代码是没有此特性的。git
2.推荐使用IDEA做为开发工具，git做为版本控制工具。spring
说明：IDEA做为当前最强大的java开发工具，其效率，性能，智能都是目前顶尖的，开发人员须要克服一下由传统的eclipse,sts,myeclipse转变到idea的不适应。数据库
3.IDEA安装lombok插件，在每一个实体类上加上lombok的注解：@Data, @Builder,设计模式
@NoArgsConstructor,@AllArgsConstructor以简化代码，在须要用到日志输出进行调试的类上可直接加上@Slf4j注解便可直接在代码中以log.xxx()进行日志输出调用缓存
说明：lombok主要起到的做用是简化代码，一些约定俗成的方法均可以直接经过lombok的注解实现。服务器
Lombok说明：框架
@Data注解：注解在类上，直接为类的全部属性植入了getter/setter方法，equals方法，toString方法，hashCode方法eclipse
@ NoArgsConstructor：注解在类上，为类植入了无参构造方法ide
@AllArgsConstructor：注解在类上，为类植入了全参构造方法
@ Builder：注解在类上，为类植入了一个Builder的内部类，该类采用构造器的设计模式，主要做用为初始化实例。
@Slf4j：注解在类上，为类植入了获取slf4j日志对象方法
根据函数式的不变性，咱们在初始化实例的时候，不容许经过new Objcet()的方法来进行，也不容许经过Class.newInstance()进行，这些初始化出来的对象太过灵活，本着权限最小化原则，代码中不容许出现。
上述第3条，加入了lombok的@Builder注解，咱们统一使用类的构造器来初始化，而且在引用前面加上val（这也是lombok的一个注解，只是不须要使用@，该注解的做用在于编译的时候将该引用修饰为final类型，符合不变性）
示例：val user = User.builder().age(18).username(“xxx”).build();
4.在声明一个变量，不管是成员变量仍是局部变量，考虑是否能声明成final类型（基本上均可以，少数须要进入代码块的，如循环体，try-catch内的不行以外），能声明成final类型的则使用final修饰，不能的，考虑有没有方式达到，实在不行的只能妥协。
说明：final类型除符合不变性之外，对JVM效率的提高（内存的寻址很是明确）也是很大的 ，单单一个体现不出效果，可是一个项目会有成千上万的变量，每个小的提高累加以后都将变成巨大的提高。
5.分层说明（重要）：但愿你们能了解下DDD（领域驱动设计）分层设计思想，
传统的咱们都是进行MVC分层，M层为model,dao,service的统称，V层为视图层，C为控制层，你们有没有遇到过这种状况，当个人Controller要调用几个带事务操做的service的时候，两种作法：(1)直接在controller中调用多个service进行数据拼装返回给视图。(2)封装一个大service，屡次调用dao知足业务后返回给controller调用。
这两种作法会形成的后果分析：(1)第一种作法，事务问题如何保证，全部的都成功，咱们才会认为成功，失败一个，就认为此次的事务是失败的，前面完成的都应该回滚，可是第一种作法明显没法保证这个一致性问题，由于咱们的事务控制是在业务层，由于咱们使用的spring框架一些缘由，controller层没法使用spring的事务代理。
(2)第二种作法，其实也是采用MVC分层设计的主流作法，一来保证事务，二来也保证了业务，无非只是增长了代码量而已。那么问题来了，那这个大service的地位你们有没有以为很尴尬呢，业务其实咱们是要求细粒度的，包括事务控制也讲究一个原子性，可是这个业务咱们能够分析下，他并非一个业务，而是多个业务组合起来造成的一个“业务”，其实在MVC分层设计中，是没有这个所谓的“业务”的地位的，只是咱们妥协，将其视为一个业务而已。
正题：DDD分层设计思想大致分为4个层：
a: 基础设施层
——本层包含了各类util类，数据库操做，缓存操做，队列操做等等一些组件操做的基本元素，像MVC中的model,dao就属于这一层。
b: 领域层（@Component）
——本层包含细粒度的业务，调用基础设施层进行业务实现，相似service层，可是要比service粒度更细，基本上都只是service里面的简单的CRUD操做。
c: 应用层（@Service）
——本层便是刚刚案例所提到的那个“尴尬业务”的容身之处，在本层要作的事：1.事务控制在本层。2.调用领域层进行数据的拼装。本层的做用在于封装了业务的复杂性，直接可由接口层调用，一步到位，接口层写逻辑是很差的行为，接口层是对外开放的，越简单越好
d: 接口层（@Controller/@RestController）
——本层的地位至关于MVC中的controller了，对外开放，调用应用层返回客户端数据。
经过上文的描述，应该能有必定的理解，我讲的比较简单明了，并且是类比MVC来进行的，真正的DDD思想内涵还望你们能多钻研，有什么领悟能够一块儿探讨，共同进步。
从上文能够看出，领域层是整个系统最“胖”的了，这也是为何叫DDD(Domain-Driven-Design即领域驱动设计)，整个系统的正常运转是依赖领域驱动的，这么设计的优点在于对系统的扩展性，可伸缩性的提高是巨大的。
包命名规范：包命名不容许出现大写字母，缘由是git对包的识别不区分大小写，但java区分，在idea中java会认为是不一样的包，可是git会认为是同一个包，提交代码，合并代码的时候会出现问题。也不要出现下划线。