服务数据映射模式

设计缘由

因为服务愈来愈小型化或者分工愈来愈精细，这样的场景愈来愈多见：

须要从多个不一样的服务（SOA服务、Restful服务）获取数据，截取其中一部分返回进行进一步处理，生成自身领域模型须要的业务数据

乍看其实很简单，就是获取数据——MAP映射数据——对映射数据执行领域业务逻辑

但实际状况可能复杂的多

获取数据

• 获取数据的时候，数据源不一致，对每种数据源要进行封装
• 数据源获取的时候，每一项业务可能获取的数据源不一致
• 获取的数据源可能互相依赖，好比B数据源的Request须要A数据源的Response
• 获取数据源无互相依赖，为了性能，可能须要并发获取，或者对每种数据源进行设置超时（可能某些数据源自带超时或熔断功能，有些没有，又须要本身实现）

单看以上每种问题都比较好解决，可是这些问题混合在一块儿的时候就很头大了

MAP映射数据

• 对同一种数据源，MAP的粗细程度可能不同，有些须要精细Map，有些只须要简易的Map
• Map代码可能散落在代码库各处，不方便以后维护的人阅读，后来的人改起来吃力，可能就本身重写了，致使有多种重复Map

---

因此萌发了写一套代码能通吃处理以上问题

目的是能：

• 最大限度重用数据源调用
• 最大限度重用数据映射逻辑
• 灵活的数据获取和映射
• 新建立数据源、数据映射能够方便集成进现有架构
• 业务变化，某些映射逻辑过期后，能够只需在一处修改（映射代码只会出现一次）

原理模型

RequestEntity封装请求类，容纳全部DataSource请求所须要的字段（能够是巨型实体）

ResponseEntity封装返回类，容纳全部Mapper映射后的返回字段（能够是巨型实体）

使用方法

1. 首先实例化DataSource的子类，一个子类表明一种数据来源
2. 建立Mapper对象，因为有TResponse协变泛型进行约束，保证数据源只有能处理的Mapper进行处理
3. 将Mapper加入数据源MapperList
4. FetchData从第三方数据源获取数据
5. GetResponse遍历全部Mapper进行第三方数据到ResponseEntity的映射
6. 若是须要从别的数据源获取，能够直接重复1-5的操做，ResponseEntity做为已经处理过的数据，能够参与到后续的映射中
7. 若是须要并发获取，能够单独写方法建立多个线程同时执行多数据源的Fetch操做

代码实现

参考火车票动态答案项目、zhixingflight动态答案项目

改进方向

MapperList也能够影响DataSource的RequestEntity

因为大量使用组合的方式，去除耦合，致使有可能须要将Mapper切分的很细，具体仍是须要使用的人来决定是否切分Mapper