java service层的粒度划分

一、前言
java web 开发有经典的MVC三层，这个现在几乎已经不再被提起，不是因为过时，而是因为早有更为细致的规范，业态也已经千变万化，现在主流的开发模式就是springboot+分布式服务+各种容器技术，但本文是要落实到基础的服务层面上。
服务设计的好坏，和微服务的服务能力和质量是直接挂钩的，可能存在两种极端。
其一：提供大量重复职能的接口，使用者信息过载，每个人都要去看这些方法之间的差异，不够直观不够简洁不够高效。
其二：一般职能的接口未能提供，这个一般是历史问题，设计者之初仅限于完成当下的需求，缺乏一个统一和前瞻的考虑，这个原因某种意义上也是上面现象提到大量重复职能接口的一个因素。
至于出现这两种现象，也容易推测原因，赶工，开发者经验缺乏，管理上缺乏约束，都是造成服务设计臃肿且功能缺失的原因。
二、service的分层设计
1、元数据。
java是面向对象语言，不单是真实世界的对象，比如一个员工，也可能是一些抽象对象，比如员工关联关系表，以此为例，在库表中可能是t_xxx_user 和t_xxx_user_rel 两张，对业务而已，元数据其实是用户信息，对微服务使用者而言，关注的也是user相关的操作和查询，我们可以称之为user相关的表，共同组成用户这个元数据。
2、原子服务
简而言之，一张表，对应一个dao（有些框架里已经隐藏或者兼任比如mybatis），一个服务，这个服务应当包含对该表的增删改查（分页）等一般功能，以user为例，我们有IUserService和IUserRelService，原子服务显然是没有具体场景的（还不能构建），和dao相比，它用vo进行通讯（不用实体，用实体在api中暴露将会是一场灾难），并且对一些实现上也进行了包装扩展。
3、职能服务（或者称为管理服务）
我们创建一个接口 名字叫做IUserManageService ，这个接口通常要把所有user相关的原子服务注入进来，比如上文的userService和userRelService，这个服务我们称之为职能服务。在这服务里，选择性的封装和暴露，比如可以设计用户注册registerUser和用户登录userLogin，这种真实的业务。
职能服务层可以引用原子服务，也可以注入其他的职能服务。
4、api的暴露选择
职能服务的接口承担真实的业务场景，这些接口不单要在api中声明，而且必须在dubbo注册中心注册（举dubbo+zookeeper为例），最终给需要的controller注册并完成相应业务。
原子服务，原则上是要对controller隐藏的，也不需要再注册中心注册，原子服务是给智能服务提供基础操作的。
这样经过一个分层，可以看出api的体量也会变小，而功能更加实用，对业务调用者是很友好的。
三、图示

image.png

image.png

四、其他
后面文章会介绍用框架约束的原子服务声明及代码生成器实现原子服务代码自动生成。