一种快捷web微服务开发框架设计

最近公司要开发一款面向幼儿园儿童健康管理的大型服务平台，由于产品部也是头一次做涉及幼儿健康领域的产品，对业务需求也不能很好把控，需求的变更就会非常大。为了提高整个系统平台业务代码的灵活性，扩展性，重用性，能快速适应多变的业务需求。我作为公司的技术总监，准备设计一款有针对性的web服务开发框架。我取名为sunny-fw。
sunny-fw框架是从传统java web mvc开发框架的设计思想演变过来。由于系统核心架构从传统一体化web架构转变为前后端分离+后台分布式的系统架构。所以， sunny-fw框架主要是用于开发后台微服务用的，核心思想是采用一组统一的控制层组件，封装大量权限管理逻辑，流程控制逻辑，异常消息处理逻辑，输入输出参数封装逻辑等。然后预留一个统一的业务接口，service层业务逻辑实现类实现该统一业务接口，集中于相应的业务逻辑的快速开发。然后在统一的控制层调用业务逻辑实现类组件。具体调用哪个业务逻辑实现组件，根据前端传递的url判定。
统一的控制层组件，主要包括了json格式输出的组件，xml格式输出的组件，excel文档格式输出组件，pdf文档格式输出组件等。这些控制组件均调用service层业务组件来完成业务逻辑处理。这样便能实现业务逻辑代码的分离解耦，以及与前端框架的极大解耦。
使用sunny-fw框架开发出来的业务组件，通过被标准的统一的控制组件调用后，对外统一了输出报文。与具体的前端无关，前端可以采用任意的开发语言，比如：android, ios, vue.js, react.js都可以。甚至是智能硬件终端。然后，同一个业务组件被不同的控制组件调用，对外输出格式是不一样的。
例如被xml控制器调用后，是xml格式报文输出。这样的灵活搭配可以满足不同终端对接口报文的需求。
控制层组件跟业务服务组件之间通过一个统一的ParameterDto数据对象实现信息交换。
ParameterDto对象里面有2个HashMap对象，一个是inputHashMap,用于保存从客户端传递过来的输入参数，另外一个是outputHashMap，用于保存需要输出给客户端的参数信息。
统一的业务接口，本质上是对业务操作方法的抽象，将所有业务方法对象，抽象为一个统一的接口。该接口名称为IBusinessService。所有的业务服务组件都实现它，遵循统一标准规范。这样就便于灵活地面向业务扩展。在IBusinessService接口基础上，我又抽象了一层业务抽象类，BaseService.主要封装了对业务效验逻辑方法，和业务逻辑流程处理方法的流程控制，预留业务效验逻辑抽象方法，和业务逻辑流程处理抽象方法。
根据我多年的软件项目经验，我对业务处理操作大致分为3类，1类是列表查询类，2类是详情查询类，3类是数据更新类（新增数据操作，修改数据操作，删除数据操作等）。第三类里面，我又细分了业务效验类，业务操作类。这样，就分为了4类的基础操作类。
程序员在实现具体业务接口时候，可以分别继承4类中的一个，来完成自己具体模块业务逻辑的封装。具体具体业务对象采用spring框架来管理，从业务对象的实例化，初始化，到最后销毁等对象全生命周期的管理。
我定义了一个注解@CheckServiceBeans，通过它来实现业务操作类对象，和业务效验类对象可以灵活搭配组合。还定义了一个@NextExecuteServiceBean注解，来实现对业务操作类功能的扩展。
当然，业务组件对象是可以在本地代码中，也就内部相互调用的，实现一定的复用性，提高编码效率。对外都是restful API 也能在更大的范围类实现SOA，分布式业务组件级别的复用。从不同角度，满足业务重用性，提高效率。