在《CURD系统怎么做出技术含量--怎样引导面试》有朋友开玩笑说都用上了领域驱动了，就不叫CURD系统了吧。这里我解释一下，怕大家对DDD领域驱动设计有什么误解。
DDD是为解决软件复杂性而生，但不仅仅可以被用于复杂的系统。它里面提到了很多技巧，其实CURD就是其中一种技巧。这些技巧适用于任何系统，哪怕是非常小型的系统，比如《CURD系统怎么做出技术含量--怎样引导面试》里提到的谦卑对象模型、充血模型。
今天咱们再提高一下CURD系统的门槛，连DDD技巧，咱也不用。就用写咱们平时都在写的最简单的接口。能说明设计理念，也能惊艳到面试官：
- 两种设计方法
- n m返回值设计
- 终态设计
- 一种思维理念
- 谁生产谁负责
两种设计方法
一个规范的系统要统一的入参标准和返回值标准，这种标准可以提高系统的稳定性，促进跨部门甚至跨公司之间更好的合作，价值很高。面试的时候值得跟面试官说一说。很多可能之前大家都做了，但是没有仔细思考其中的逻辑，你思考清楚了也会让面试官眼前一亮。
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}
这样就一目了然。有的时候可能是调用方本身的设计问题，但是如果被调用方能通过巧妙的设计帮助调用方。一旦遇到问题，调用方可以自己先进行排查，不用马上联系被调用方帮忙。即节约了自身的成本，又体现了专业性，何乐不为。
终态设计
在《实战并发-使用分布式缓存和有限状态机》里我讲过有限状态自动机。有限状态机涉及状态流转。状态从分类上可以分成三种：初始状态、中间状态和终态。这段时间不是一直在将TCP底层通信嘛，来一张TCP状态的流转图体会一下：
有限状态机的重点在于有限，要有起点和终点。也就是一定要有终态。在《稳定性三十六计-超时处理》我讲过：
在传统的单机系统中，调用一个函数，要么返回成功，要么返回失败。这就是两态系统(2-state system)。
在分布式系统中，由于系统是分布在不同机器上的。还可能有一种状态叫：超时。成功、失败和超时是分布式系统调用的三态。
超时不是终态，而是一种中间状态：最终有可能下游是成功了，也有可能是失败了。这时候我们需要在超时之后推定一种状态，推定成功或者失败。究竟是成功还是失败因功能而已。
比如付款操作，不知道是否成功就推定是成功的，那用户可能没有付款就拿到了商品或者享受了服务。商家就会资金损失。所以一般会推定失败。让用户再次支付。最终通过查询或者对账发现用户实际是支付成功的，可以再把钱给用户退回去，保证交易的公平性。
退款恰恰相反，需要推定成功。告诉用户，钱退给你了。最终通过查询或者对账发现实际是退款失败了，可以系统重新发起退款，直到真正退成功为止。
后台管理系统也很需要这种终态设计。比如发布系统，发布了一个功能，发布系统如果出现了问题，这次发布没有结束。用户可能没有办法进行下一次发布。这时候可以设置超时自动结束，防止未结束的流程始终在那里，起码会干扰视线，增加判断成本。
一种思维理念
谁生产谁负责
在《设计开发中要避免的两个坑和一种可借鉴的设计思想》中我建议项目千万不要叫base、basic之类包罗万象的词，容易造成边界不清。
之前有人就跟我说过：这个数据我们只是提供，数据不是我们自己要用，而是有几个团队都要用，放在我们这里不合适。有base模块，那就应该放到base里啦。
从领域上来说，这种思维理念不对，数据应该谁生产谁负责。
举个例子：我们创建了一个系统，是toC的。开发这个系统的人能说这个系统是十几亿中国人用的，放在我们这里不合适，让十几亿中国人自己维护去？用户有很多，系统开发源头是一个，这就是谁生产谁负责。对于系统是这样，数据也是这样。
总结
这种小的设计技巧还有很多，比如两码一态设计。仔细思考自己的工作，你也许会被自己惊艳到。
