驱动api_消费者驱动契约已死？

吐槽文一篇。

契约的一些问题

在实践前后端分离的这些年来，已经诞生了一些技术与工具让前后端进行沟通：

契约的 Mock 服务（Mock Server）。用于模拟一个服务器，为特定的接口返回特定的值。
契约测试。对前后端协定的 API 进行测试。
前后端胶水层。如 BFF （Backends for Frontends），根据客户端的需要对 API 进行聚合、适配、裁剪等。

而使用这些工具的时候，往往容易出现一些问题。

消费者无法驱动的契约

消费者驱动，顾名思义就是在我们协定契约的时候，按消费者的业务实现角度，与生产者一起协定契约。在实践上，往往由于后端在项目中的主导地位导致：协商的结果不会按消费者需要，而是按生者需要来生成契约。造成这种结果的因素有很多：

后端才是实现方。所以，你常会听见：『你行，你上』，笑~。
从实施成本考虑。诸如于跨服务调用的成本等等
后端的职级高——毕竟后端已经有了几十年历史了。
为了更『美』的后端架构——导致了更『差的』前端架构。

我的意思并不是说，按生产者来主导有什么问题，而是配不上『消费者驱动』这五个字。诸如于我们获取某个 API 的时候，前端所需要的是相关的信息，而不是对应的实体 ID。而后，再由前端去获取对应实体的信息。从逻辑上来说，由前端获取或者后端获取，从技术上来说，并没有多大的问题。但是从用户体验上来说，并没有那么友好。后端间的 API 调用，可以是几十 ms 级别的；而前端多调用一个后端 API，在网络上的传输时间，往往都是几百 ms，乃至几秒。

生产者的契约测试

所以，让我们再看看各个团队所宣称的消费者驱动的契约测试。

消费者驱动的契约测试（Consumer-Driven Contracts，简称CDC），是指从消费者业务实现的角度出发，驱动出契约，再基于契约，对提供者验证的一种测试方式。

如果你不是消费者驱动的契约，而是后端一口气定出来的接口，你怎么能叫『消费者驱动的契约测试』？？？？按这样的做法，它只能叫生产者的契约测试。

既然是生产者的契约测试，那么它就无法保证说：API 修改不影响消费者使用——因为消费者压根就没有参与到契约的制定，生产者可以按照自己的需要来修改契约。

所以，生产者到底是在给谁测试？又是在测试什么东西？

契约测试的契约作为 Mock Server——不行

在大部分的项目中，对于契约的使用存在问题，即模式错了。契约测试需要围绕业务流程施展，而不应该相互隔离。如果契约的用例不丰富，便无法串起整个系统的流程。而作为 API 的提供方，应该保证业务逻辑是可以串联起来的。从用户的登录开始，到用户获取数据，展示列表页，能进入详情页等等。

我们做契约测试的目标是，让代码修改不影响 API 输出。后端需求一改，契约测试会挂，后端知道出现问题，会进行修复。如果前端用的是契约测试的契约提供的 Mock Server，前端的测试也会挂，这样问题就不会往后流。

所以，契约不应当给前端做本地开发和测试。

没有契约的 Mock Server——不行

对于小团队来说，去采用原始的 API 方式反而更加有效率；对于大团队来说，这样的方式并不可行。

既然，沟通那么麻烦，那么我们就分开吧。如果契约和 Mock Server 是分开的，那么维护前端 Mock Server 的人很很难识别到修改。相关的问题，在测试不及时的情况下，有可能在上线后才发现。

也因此，从理想情况来说，这个 Mock Server 是契约动态生成的，并能根据后端现有最新的契约更新。或者，后端在实现契约测试时，要做的是只测试部分数据，而不是为了测试而测试。

只有 DDD 的微服务——不行

尽管 DDD 模型不一定非要与 API 绑定，但是由于种种原因，真正在实践的时候，就不是这么一回事。我们可以看到在很多的项目里，DDD 返回的实体资源，最后可能与 API 的字段一致的。但是它并非是业务上想要返回的逻辑，各个客户端（PC Web、小程序、Android 端、iOS 端等）还都需要进行二次的处理。

这就是为什么，DDD + 微服务，一定要配合一下 BFF 的原因。