引子

十几年前的一天，有段时间在读张爱玲的小说，同事看见了就说原来你爱看这种东西。我到现在都不知道他说的是哪种东西。那时候我只是单纯的觉得张爱玲写的东西有种特质，这种特质掌握了做什么事情都不会太差。后来我想明白了，这种特制叫做：善于运用技巧。

举个例子，张爱玲有个神作【金锁记】，女主经历了不幸的一生心灵扭曲，害了儿女的一生。她女儿名字叫长安。女儿30岁了，终于有人上门提亲，她却说自己女儿怎么怎么不好，还抽大烟，最后吓跑了提亲的人。这时候是这么描写长安的：

长安悄悄的走下楼来,玄色花绣鞋与白丝袜停留在日色昏黄的楼梯上。停了一会,又上去了,一级一级,走进没有光的所在。

张爱玲施展她高超的绘画功力，手绘了一个电影中的分镜。不写长安的表情，不写她的心里，只给她的脚一个特写镜头。黑白的主体轮廓，昏黄的背景，画的尽头没有光，简直是野兽派画风的一幅画。

镜头不动，只有人物的脚在动。整体包含三个画面：第一个画面是走下楼梯；第二个画面，停了一会儿，画外音：听到了提亲时的对话正好说到抽大烟的事；第三个画面是沉重的脚步走回了没有光的所在，那就是她的余生。

此时无声胜有声，一切尽在不言中。

在 有朋友开玩笑说都用上了领域驱动了，就不叫CURD系统了吧。这里我解释一下，怕大家对DDD领域驱动设计有什么误解。

DDD是为解决软件复杂性而生，但不仅仅可以被用于复杂的系统。它里面提到了很多技巧，其实 CURD就是其中一种技巧。这些技巧适用于任何系统，哪怕是非常小型的系统，比如 里提到的谦卑对象模型、充血模型。

今天咱们再提高一下CURD系统的门槛，连DDD技巧，咱也不用。就用写咱们平时都在写的最简单的接口。能说明设计理念，也能惊艳到面试官：

大纲

三种设计方法

n+m返回值设计

概述

一个接口入参有n个值，需要的返回值是m个值。在返回值中可以把入参和返回值一起返回。

这种设计便于追踪和排查问题：

为了防止调用方没有日志追踪号、打印日志过多等原因造成不方便跟踪请求的问题，可以设计返回值将入参一起打印。这样调用方可以通过一条日志方便的获取到入参和返回值。线上排查问题会非常方便。

建议使用场景

假设有个场景，调用方的系统设计不方便请求追踪，比如没有线程追踪号。在高并发量场景下可能日志是这样的：

1、thread-1| className|参数1：11，参数2:11

2、thread-2| className|参数1：22，参数2:22

3、thread-1| className|参数1：33，参数2:33

4、thread-2| className|返回值：44

5、thread-1| className|返回值：55

6、thread-1| className|返回值：66

你能决定55和66对应的谁是1，谁是3的返回值吗？

但是如果返回值包含了入参，就好办多了，举个返回值例子：

thread-1| className|{参数1：11，参数2:11，返回值：55}

这样就一目了然。有的时候可能是调用方本身的设计问题，但是如果被调用方能通过巧妙的设计帮助调用方。一旦遇到问题，调用方可以自己先进行排查，不用马上联系被调用方帮忙。即节约了自身的成本，又体现了专业性，何乐不为。

不建议使用场景

1、公司内有规范的、完善的、各个部门严格执行的全链路追踪标准

2、入参很大，不建议全量打印，可选取部分关键或者完全不用

终态设计

概述

在 里我讲过有限状态自动机。有限状态机涉及状态流转。状态从分类上可以分成三种：初始状态、中间状态和终态。这段时间不是一直在讲TCP底层通信嘛，来一张TCP状态的流转图体会一下：

有限状态机的重点在于有限，要有起点和终点。也就是一定要有终态。在 我讲过：

在传统的单机系统中，调用一个函数，要么返回成功，要么返回失败。这就是两态系统(2-state system)。

在分布式系统中，由于系统是分布在不同机器上的。还可能有一种状态叫：超时。成功、失败和超时是分布式系统调用的三态。

超时不是终态，而是一种中间状态：最终有可能下游是成功了，也有可能是失败了。这时候我们需要在超时之后推定一种状态，推定成功或者失败。究竟是成功还是失败因功能而已。

建议使用场景

比如付款操作，不知道是否成功就推定是成功的，那用户可能没有付款就拿到了商品或者享受了服务。商家就会资金损失。所以一般会推定失败。让用户再次支付。最终通过查询或者对账发现用户实际是支付成功的，可以再把钱给用户退回去，保证交易的公平性。

退款恰恰相反，需要推定成功。告诉用户，钱退给你了。最终通过查询或者对账发现实际是退款失败了，可以系统重新发起退款，直到真正退成功为止。

后台管理系统也很需要这种终态设计。比如发布系统，发布了一个功能，发布系统如果出现了问题，这次发布没有结束。用户可能没有办法进行下一次发布。这时候可以设置超时自动结束，防止未结束的流程始终在那里，起码会干扰视线，增加判断成本。

不建议使用场景

这十几年的开发还没有遇到过什么场景不需要终态。但是有些终态是隐式的。举个例子：

在 里提到的 事件溯源模式 ，就是说比如在一张数据表中，只做数据记录用，只有插入操作没有更新操作。比如一个用户行为记录表，会记录用户什么时候登陆，因为用户是APP登陆的，所以2年都没有登出操作。是不是就没有终态呢？我们从这张表本身来看，因为是事件记录，所以落库的那一瞬间，状态就是「记录完成」，本身就是终态。

两码一态

概述

两码是指系统码和业务码，一态是说通过两码就可以确定最终的状态。

很多情况下咱们是已经隐式的使用了两码一态，比如自己设计了一个单点登录接口给外部调用。一般是这样设计：

实际上这个接口有个返回值，比如登录成功会返回用户信息或者直接返回 是否成功的布尔值 。但是这个接口是给外部调用的，需要包装一层，最终就是返回 Re sult <User > 或者Result<Boolean>。Result是怎么定义的呢？

@Datapublic class Result<T> {privateboolean isSuccess;privateString errorCode;privateString errorMessage;private T data;}

有没有感觉和自己平时写的代码很像？

分析一下：最外层isSuccess很多人都把它当成最终的状态来使用。比如在这个登录的场景下就代表了登录成功。但是如果isSuccess=true但是data==null？这就让人很迷惑，究竟是成功还是没有成功呢。成功了为啥我的数据没有吐给我？

稍微合理一点的是 isSuccess = true 代表系统处理成功，就是没有抛出什么异常。究竟业务是否成功看data。

在更加规范的场合是这么定义的：

@Data
public class Result<T> {
private String sysCode;
private String sysMessage;
private String bizCode;
private String bizMessage;
private T data;
}

如果系统码sysCode为成功，是否业务成功需要看bizCode；如果sysCode失败，bizCode就不用看了，也很可能根本就没有拿到；如果sysCode为失败，看系统码是多少就可以定位问题范围，或者至少说这个问题开发人员应该查查；如果bizCode为失败，如果业务码也能定位问题范围，而这种问题一般不需要开发人员来处理。

建议使用场景

比如后台管理系统中，可以定义：连接数据库异常、空指针异常等为系统失败，对两种异常分配不同的系统码，比如S001、S002；系统正常码可以分配S000；必填参数为空、参数校验失败为业务码，比如B001、B002；业务正常可以分配B000。最终状态由两个码共同决定。当系统码异常开发人员需要处理。当业务码异常可以联系运营人员培训一下怎么老填错或者不处理。

比如我在之前的文章 中设立过一个场景

假设我在超市买了我喜爱的经典搭配：烤肠+酸奶。然后我就微信扫码付款了。付款时序图大体是这样的：

不用理解这个图，关系不大。我要说的是像支付这种场景后面会涉及多个环节，比如微信支付自身还要调用银行呢。

这时候的系统码和状态码中可以加一位，代表那个环节。比如系统码定义：

WS000、 W S 001…… BS 000 、B S001 ……

S代表系统。W代表微信，比如下游请求银行，银行处理成功了，自身异常了，会设置这个码；B代表银行，比如银行自身异常了会设置这个码。

同理，业务码 定义 ：

WB 00 0 、 WB 001…… BB 000 、BB 001 ……

第二个B代表业务。W代表微信，比如自身校验没有通过，根本不会请求银行，会设置这个码；第一个B代表银行，比如银行最后发现用户余额不足会设置这个码。

不建议使用场景

如果是给一个进程内部自身使用的，当然就没有必要定义这么复杂。