提高java开发效率

1.鼓励使用java8的函数式进行开发，主意其不变性特性。

说明：函数式开发在多核服务器上运行效率跟核数呈正相关，而传统java代码是没有此特性的。

2.推荐使用IDEA作为开发工具，git作为版本控制工具。

说明：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方法

@ NoArgsConstructor：注解在类上，为类植入了无参构造方法

@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会认为是同一个包，提交代码，合并代码的时候会出现问题。也不要出现下划线。