‘5Ws and an H’流水账和组件

在前面的贴子“彩色UML建模、SOA和《目标》”中，提到了‘5Ws and an H’流水账，这里进一步阐述一下。

流水账

• When：这个业务事件何时发生？
• Who：谁参与这个业务事件？
• What：这是个什么事？涉及什么物品？
• Where：这个业务事件发生在哪里？
• Why：为什么会发生这个业务事件？
• How：这个业务事件以何种方式发生？有无细节？

让我们来看一个例子：
特征：为客户打印发票（收据）

• When：记录下“打印发票（收据）”这个业务事件发生的时间
• Who：参与这个业务事件的人有两个：客户和业务员
• What：这个业务事件是“打印发票（收据）”，涉及到一张纸质发票（收据），上面有序列号
• Where：这个业务事件发生在公司旗下众多连锁店的一个里
• Why：因为客户付了一笔款，客户付款是前驱业务事件
• How：用户付款时享受了折扣优惠，需要在发票（收据）上注明

当我们把一个业务事件的这些方面都记录下来时，信息就完备了。值得一提的是，在具体业务事件中，上面的每个因素都可以有多个具体的值。例如，在持续集成中，因为前面有3次提交，然后在5分钟内没有新的提交，这触发了一次持续集成。那么，这次持续集成事件的前驱业务事件就有3个。

组件
这个业务事件构成了一个组件，它对使用的上下文做了一些假设。如果这些假设没有变化，这个组件就不需要改变，可以复用。

也可以把这个组件看成一个独立的数据源，它提供对这个数据源的数据分析统计功能。例如：

• 这个月哪个业务员开出的发票最多？
• 从上次领发票本到现在，某个连锁店开出了多少发票（是否要提醒领新的发票本）？

如果从流水账和总分类账的观点来看，可以认为“5W and an H”类似于“科目”，它们对流水账进行了分类。

组件粒度
组件粒度也就是业务事件的粒度。“进行一次销售”这个业务事件可能由“下订单”、“付款”、“打印发票”这3个小粒度的业务事件组成。 于是，我们可以在“进行一次销售”这个业务事件的“How”部分，标明它由3个明细业务事件构成。如果我们还允许一周内无条件退货，那么还可以包含“退货”的业务事件。

小粒度的组件组合起来，就构成了大粒度的组件，系统以这种方式体现伸缩性。这样做的好处在于：

• 简单一致地伸缩，设计小系统和设计大系统的原则一样
• 在不同的抽象层面上看系统，如操作层面和管理层面

总账会计师和CIO
总账会计师要能够从企业的总账中分析出企业的盈利能力和风险。CIO要能够从业务事件流水账中按“科目”进行整理，通过分析找到实现企业目标的风险和机会。