最近一直在想一个问题，如果目标是煮一顿饭，事件应该如何划分。
例如，这顿饭的目标是做三个菜，番茄炒鸡蛋，红烧排骨，小炒黄牛肉。那么做饭这件事，有两种事件划分方式，应该选择哪一种：
方式1：
买菜->洗菜->炒菜->装盘->上桌
方式2：
为三个并行的事件：
番茄炒鸡蛋：买菜->洗菜->装盘->上桌
红烧排骨：买菜->洗菜->装盘->上桌
小炒黄牛肉：买菜->洗菜->装盘->上桌
后面仔细用需求分析的思路发现，不一定，我们要看那个做菜的人实际是怎么做菜的。
首先我们找这个活动里面的主题域，我们设置为：菜市场，厨房，和食厅。在这三个地方要做的事情（业务范畴）是完全不一样的。
主题域
然后我们看下做一顿饭，需要做什么事
是下面这种吗，我想这种应该更多见于初学者：
image.png
高手都是下面这样的：
image.png
这里想提出的一个问题是：洗菜是否也可以叫做事件？如果可以的话，那么洗菜的活动步骤是怎样的，而每个步骤要如何写用例呢？
题外话
突然在想什么是沉浸式的体验。以往的软件系统都是一个黑盒子，加盖了一个大屏幕，人类与之交互，都是通过这个大屏幕，这种交互就很机械化，因为人永远都在系统的外部。但是当我们把菜市场，厨房，食厅也当成是一个个的小系统的时候，那么人和这些系统的交互，都是在这个环境里面的，系统不一定是一个真的有形的实物了，人也不再是独立于系统的外部，人的存在，也是系统的一部分，例如人炒菜，其实炒菜的过程除了厨房本身的炉灶，锅之外，也需要人的炒的参与，我想，这应该就是沉浸式体验的比较好的解释了。
网友评论