系统设计的目的是更好的支持需求
我们常说，只要业务能将你的需求描述清楚，能自圆其说，我们就有办法实现。
这其实是系统设计的最理想的状态，
如果业务没想清楚，那么在系统实现中，一定会把问题暴露出来。很多时候，问题的暴露源于没有考虑周全亦或都没有考虑这种场景！
比如，从业务层面上允许商品超卖，但又没给出超卖了怎么处理，这时候，系统就处理不了。
那么，语言沟通与设计有没有关联性了？
我们设计的系统有一个很有意思的特点，理解成IO+计算，人输入命令，计算机将信息处理完成后输出结果，映射到真实世界。
我用微信聊天、我在淘宝买东西、商家要做活动、下单送礼品、用户写文章发表、闹钟到点提醒、电脑到点自动关机等等
这些一个一个的事件、命令、动作似乎都可以理解成语法中的主谓宾。
如果系统设计也按这种主谓宾结构作为设计思路，那么一切与业务的沟通，就要找出业务需求中的主谓宾，对应到系统中。
例如
业务想在双11做一场活动，活动规则是用户必须每天签到，签到次数到了就可以得到一张大额券。
且不讨论细节规则合理性问题，在这个需求上，我们拆解语法。
1，业务做一场活动
2，用户每天签到
3，签到达到门槛获得一张券
核心逻辑就这三点，先找出需求中的主谓宾
业务（主）建（谓）活动（宾）
用户（主）参与（谓）活动（宾）
用户（主）签到（谓）完成任务（宾）
用户（主）完成活动任务（谓）获得券（宾）
建模
业务和用户为主语，创建、参与、完成、获得为动作谓语，活动、任务、券为宾语
以此得到这个需求的实体模型：活动、任务、券
后续业务认为完成任务不发券，发现金，那此时模型中的实体就不是券，而是现金与券的抽象，比如奖品。
这个思路与最近流行四色建模方式有一曲同工之秒。
四色建模
先了解下四色建模步骤
第一步：寻找要追溯的事件
第二步：识别“时标对象”
第三步：寻找时标对象周围的“人、地、物”
第四步：抽象“角色”
第五步：补充“描述”信息
四色建模思路翻译成主谓宾就是
第一步：找谓语动词，也就是事件
第二步：找宾语，也就是时标对象
第三步：找时标对象的”人、地、物“，其实就是找到主语
第四步：找到主语后，分类、抽象
第五步：补充”描述“信息，就是补充领域属性信息
主谓宾在系统设计中的应用
- 分类找出各自的语义
- 建模板
- 建实例
举例流程并非线上真实流程，而是推演的过程，在此流程推演过程中，发现许多原来设计不合并且难自圆其说的问题。在此说明！
结束语
建模中有个很大的风险是当业务不明确时，当时建模型在业务发展后期已不适用，需要更改模型，而更改模型会引入更多成本。所以，多与业务沟通中了解业务尝试方向，尽量减少建模风险。
而本文中的主张也同样有这种风险，因为参与的项目有限，能够拿这套理论推演的样本有限，难免有疏漏之处，如果有，请指出一起完善。
