外观模式。

设计模式这些，其实就是一种规范，一种优美的约束，所以主观能动性较大，轻轻变化一点点花样，又发明一个新模式，所以除了比较重要的，实际项目中用到的几种常用设计模式外，个人感觉大可不必全部背一遍，因为有的确实非常非常类似，可能你在日常编码优化中不知不觉又使用到了某种名字特别高大上的设计模式，但是你却不知道它有个这么高大上的名词。

所谓外观模式，其实就是把一些固定的业务调用逻辑进行封装，减少调用端的使用复杂度，因为业务逻辑这些东西，很多时候我们根本不用自己去绕，只要通过一个接口传参并且获取返回值就行……这个就是所谓的什么外观模式

例如：
你可以拿到用户id，需求要你获取用户所有购买过的商品图片
先通过用户id获取订单order，再通过所有订单编号order id取得订单明细order detail ，从订单明细获得订单商品goods id，最后，通过订单商品goods id去素材库获取goods image。
这么绕的流程，就算不用自己写接口，全部都是现成的零散功能接口，也不可能让调用方自己调三四套服务的接口吧？于是我们定义一套中间层API，专门提供一个接口叫做getGoodsImageByUserId之类的，这个接口底层自己走Http或者RPC调用去调那堆零散接口，这样对外部来说就很友好…特别是前端只需要调用一次接口就可以，不然你跟前端说功能都有，但是要对接七八个接口，前端可能当场跟你打起来…

具体代码例子就不写了，其实很多架构也有这种设计思想在里面，没啥好说的。。。