一.问题描述——接口联调过程中反复修改代码
目前正在做一个项目，项目小组共计7人。设计Android，ios，web三个大平台，后端使用springcloud。
由于后端的开发速度快于前端，所以后端大部分接口都已经写完了，前端还很大一截，等到后面开始联调的时候就出现了很多的问题。
- 【后端接口与前端逻辑不对应】一是由于后端同学是对着线框图独立进行接口设计的，所以等联调的时候却发现，有很多接口都不能完全达到要求，有时缺少一些返回信息，有时缺少一些参数，有的甚至逻辑上不正确
- 【界面的修改导致前后端代码的大幅修改】另一方面，随着线框图的不断修改设计，导致前端后端均发生了很大的改动，甚至将之前的代码推翻，重新编写，这个开发成本是很大的。
二.问题分析
原因：
1. 由于项目初期没有统一接口文档，所以后面的开发是的接口不能正常使用
2. 界面修改过程中，底层逻辑是不变的，原则上后端接口不需要进行大幅的修改
困难：
1. 在项目初期，需求的变化是很大的，系统暂未完全成型，很难敲定一个接口文档，之后不去修改
2. 时间上面也不太能允许去花费大量时间在接口的详细设计上面（在设计过程中既需要考虑当前版本页面数据的展示，也要考虑未来可能增加的页面数据展示。另外，业务的底层逻辑必须完全走通，并归入接口设计中。）
三.解决方案
1.部分接口应当是面向底层逻辑的，他们是不会改变的
这里以springboot框架为例：
之前的开发顺序，是按照下图从左至右顺次开发，每次过来一个需求，总是去controller里写个接口，然后写个业务接口，再去实现他的业务逻辑，最后进入持久层操纵数据。
这里有这样几个问题：
- 1.controller到service大多为单一关系，且一般一个controller方法对应一个service接口，对应一个imp的实现类，然后该方法中有很复杂的业务逻辑实现。
- 2.当修改顶层接口内容时，会导致底层的impl实现类有较多修改，当业务逻辑逐渐复杂过后，这将是很痛苦的事情。
- 3.各个类之间的方法调用关系较为单一，导致impl中代码特别冗长，不易维护。
改进：
这里将service提到了前面，按照从左至右的顺次开发程序员应当根据业务逻辑先编写service中的接口，并且这里的接口尽量做到职责单一，同时用于实现的方法也应该不止一个。
比如：一个付款的接口，他应该有微信支付，支付宝支付，银行卡支付等多个实现类
2.注入领域驱动设计的思想
也就是在编写service类的时候，考虑到这各方面。将业务系统的领域类挑选出来，划分领域边界。一个领域类就是一个controller类，每一个对外界提供的接口就是他的行为。
每一个行为的构成应该是有很多个步骤组成，而这些“ 步骤”就是service类中的一个个java接口
举个例子：一个dog类，他应该有“行走”这个行为，于是dog这个controller中有了一个叫做“行走”的接口，而这个行为是需要多个动作相互配合的，可能是由service中的“腿的移动”，“摇尾巴”，“吐舌头”，“晃脑袋”等多个具体步骤合在一起的。
也就是先编写service中的各个“步骤”，然后再将这些“步骤”进行组合从而得到了最终呈现给用户的api