KISS原则在订单装运模型中的应用

导读：Keep it Simple and Stupid 是软件工程师挂在嘴边的一句话，然而如何才能做到 KISS 原则，却是众说纷纭。本文作者以订单装运与订单支付为例，展示没有充分理解业务复杂性的 Keep it Simple 与实际可以工作的模型之间可能存在多远的距离，适合广大工程师阅读。

作者简介：杨捷锋，曾就职于南开戈德集团、普天集团等公司。作为独立技术顾问曾为海尔集团、沈阳飞机工业集团、上广电NEC、天马微电子等企业提供软件开发与技术咨询服务。目前在一家创业公司担任技术团队负责人。有大型企业应用软件的分析建模、大型开发框架（ORM、IoC 等）的架构经验，多年一直未脱离技术一线的编码工作，近年自认为对系统分析、数据建模、领域驱动设计、项目管理略有心得。

在开发软件的时候，我们经常听到长者传授人生经验：

“避免过度设计！”

“保持简单，KISS 你懂不懂啊？”（Keep it simple stupid，即所谓 KISS 原则啦。）

……

敏捷宣言也说了：

• 可以工作的软件胜过面面俱到的文档

• 响应变化高于遵循计划

So，还等嘛？你们赶紧开始编码吧！

“老大，编什么码啊？这次要做什么我还没搞清楚呢。”你说。

哦，忘了说了，这一次，你们要做的是电商项目。甲方爸爸说了，他要的其实很简单，照着某宝某东抄就很 OK。对了，单子已经签了，大单子，你们老板拍着胸脯保证两个星期后交付。

嗯，再简单的系统，做一下数据模型的设计还是要的。

你，作为开发团队的首席，打开某宝 App，进入“我的某宝”页面，看到“我的订单”分成了几类：

• 待付款

• 待发货

• 待收货

• （待）评价

• 退款/售后

嗯，就从这个简单的地方开始，先来设计一下订单相关的实体。

你是这么考虑的：

订单与订单行项

订单的职责，是记录客户订购了什么东西（也就是“产品”，Product）。一个订单（Order）可能有多个行项（Order Item），表示在这个订单中，客户订购了什么东西、多少数量。

比如，张三可能下了两个订单，两个订单的信息如下表所示：

然后，你决定给订单增加几个物流和支付相关的属性。

现在，Order 的属性是这样的：

• OrderId。

• IsPaid。是否已支付。

• IsShipped。是否已发运。

• IsReceipted。是否已收货。

• ……

So easy！一顿操作猛如虎……两个星期后，系统初步开发完毕。

现在，你们对代码的质量有十二分的自信：甲方爸爸用了它，分分钟挑战某宝某东，三年纳斯达克上市、走上人生巅峰。你们拿着系统到甲方公司那里做演示。

看了你们的演示，甲方仓储部门的人提出问题：

客户下的订单，并不总是能够一次性的把订单中的所有东西都发货给客户的。也许因为没有货，也是因为要发货的时候发现仓库里的货已经损坏了。碰到这样的情况，我们会跟客户商量，很多时候，我们是需要先把一部分产品/数量先发给客户的。

听了这个说法，你感觉事情好像有点不妙。你们老板也参加了会议，他对你说：“把这个需求记录下来，马上改。”