承接上一篇文章，在煮饭的业务里，问初学者做菜的流程里面，洗菜是不是也可以当成一个完整的事件。
我想回答的是“买菜都是事件了，洗菜也可以是事件”。
对了，昨天的流程还遗漏了切菜，还有菜品的腌制环节，才想起来，暴露了我不做菜的本质。
今天早上走去公司的路上，在想怎么样的颗粒度划分，才能称之为事件了，想来想去，还在为什么单独洗个番茄，做事件就不合适烦恼。也没有答案，总归，也就不纠结了。可能在对事件的细分上，总是要有点层次感，才能在宏观把控的时候，抓住方向。在梳理流程脉络的时候，不纠结与细节。在真正应对细节的时候，能颗粒分明。这个问题就等后面有了答案再说了。
接下来，讲下洗菜的流程，流程过程的活动，以及活动详细的步骤
因为是三道菜的原材料一起洗，所以，要洗的东西有：
番茄，排骨，黄牛肉，芹菜，辣椒
这就简单，番茄芹菜泡一会儿水再洗干净，排骨清洗后小火过血，辣椒简单洗一下就可以了。黄牛肉也简单洗洗吧。
流程过程的活动，洗番茄，洗排骨，洗黄牛肉，洗芹菜，洗辣椒，可以顺序着来，也可以并行着来，按着习惯和食材的特性就可以了。
[补充一个活动图]---鼠标没电，假装有活动图一个
我们可以通过分析这个活动图，活动图有执行者，没有写出来，但是是要有执行者，活动才能执行，这个时候，我们就可以建立针对洗菜这个事件下所有的活动，建立用例图了。
[补充一个用例图]假装用例图在
针对每个用例，我们通过“用例规约”详细地描述每个活动的活动过程
例如：
用例【煮饭大厨洗番茄】
用例规约如下：
利益相关者：吃这顿饭的每一个人，煮饭的人
操作者（用户）：煮饭大厨
前置条件：厨房已有现成的菜品
业务步骤：
1）煮饭大厨拿到番茄
2）煮饭大厨拿碗盛水
3）煮饭大厨把番茄放在碗里泡水5分钟
4）煮饭大厨拿起番茄
5）煮饭大厨把番茄放在砧板上
6）煮饭大厨去掉番茄的蒂
7）煮饭大厨拿刀切番茄，切成一瓣一瓣的
8）当番茄已经全部切成瓣之后
9）煮饭大厨将番茄放到盛生食的碗里面
业务规则：
1）番茄拿到之后，要检查，如果腐烂，则扔掉
2）番茄泡水要把整个都泡在水里
3）切出来的一瓣一瓣番茄，要像橘子剥成的那种效果
4）....
在用例规约都写出来了之后，基本就把整个做饭的过程，在业务层面做了规定。
我们回顾这两篇文章，做饭的业务需求分析过程，就是：
- 明确业务目标
- 分析主题域
- 寻找业务事件和事件流程
- 整理业务活动和活动流程
- 切换视角，输出活动用例
- 编写用例规约，凸显业务步骤
在这个过程，我们对业务的分析，从宏观到微观的过程如下：
业务目标->主题域->业务事件->业务活动->业务步骤
[补充完整的分析结果过图]
想想也是挺有意思的，如果把这个世界当成一个大系统，那么针对这个大系统之上，人类要去实现一些所谓的价值，或许就可以转化成业务目标，然后通过需求分析的方式，像剥洋葱的方式，一步一步的分析要做哪些事，并且在这里面细化，何人，何时，何地，何种约束和规定，何种可利用的资源。便有可能可以达成。
感悟，书本《软件需求最佳实践》，或许换一个角度，可以看到，不只是适用于软件需求的实践，可能还可以适用于其他的需求的实践。还是谢谢作者，给我带来了很多新的关于软件需求，关于生活的思考。