如何落地业务建模(3) 将模型作为统一语言

• 统一语言可以是模型本身吗

  • 事件建模法的基本原则1：通过事件表示交互

  • 事件建模法的基本原则2：通过时间线划分不同事件

  • 业务是模型的隐藏维度

  • 催化剂建模法

  • 角色-目标-实体法（Role-Goal-Entity）

  • 事件建模法（Event-Based modeling）

  • 事件风暴法

• 怎么才能更有效地获得事件流

  • 四色建模法的核心逻辑：从收入流与成本结构中寻找事件

  • 四色建模法的具体操作流程

  • 头脑风暴法的不足

  • 四色建模法(4 color modeling)

统一语言可以是模型本身吗

前面讨论过统一语言的必要性，因为业务维度在领域模型中被隐藏了，而且需要一个缓冲来发现、描述模型中不存在的概念。但这里有一个隐藏的前提假设：最终建模结果将是原味面向对象范型的模型，因为这类模型会将业务维度隐藏。

业务是模型的隐藏维度

在极客时间专栏的例子里，用户可以拥有多个专栏，而这些专栏可能是自行购买、朋友赠送、抽奖获得的，而这些都被隐藏在模型的抽象中了。
一方面，这正体现了模型抽象能力的强大，制药厂是相似的数据关联，业务逻辑就可以被保证，细节则可以被忽略；而另一方面，这也增加了业务方理解模型的难度。业务方很难从领域模型中感受到业务维度如流程、交互、功能、规则、价值等等。

如果有办法可以将隐藏在领域模型中的业务维度展开，使业务方能够理解不同的业务流程是如何作用于领域模型的，那么业务方就能够判断领域模型是否准确捕捉了业务概念，以及技术方是否真正理解了需求；这时候就可以把模型本身作为统一语言了。

这种模型称为业务友好与可读的模型，构造这类模型的方法有很多，总体有两个方向：

1. 催化剂建模法及其变体(Catalysis Modeling and its variants)

2. 事件建模法(Event-based Modeling)

催化剂建模法

催化剂建模法或催化剂方法是一种尝试将流程视角引入对象建模的方法，它产生于DDD之前，1996年前后。
它有一个称为共享词汇表的核心实践，可以看做催化剂版本的统一语言。但与DDD的区别在于，共享词汇表只包含领域模型的名称，其余的业务逻辑都通过模型自身来表达。
催化剂方法更强调对模型本身的构造，而不是像知识消化那样依赖一个试错的过程去逼近真相。是一种重设计（Big upfront design）的方法。
然而生不逢时，发表后没几年就赶上了敏捷运动，于是迅速被人遗忘了；当催化剂方法在读进入我们视野的时候，是因为我们需要寻找一种更具业务表现力、可作为统一语言的模型，于是催化剂方法又被重新拾起，作为一种将业务维度在领域模型上展开的方法，被引入到DDD中。但我们还是嫌弃他颇为厚重的建模流程，最后逐步被轻量化，产生了很多变体。

催化剂方法最大的特点在于将交互显式地建模到对象模型中；交互（interaction）即可以代表业务流程，也可以是用例或者系统功能，通过使用关系（uses）表示在流程或功能点上使用了哪些对象模型，相当于通过角色和交互为对象模型打了标签（tag），从而将隐藏在模型中的业务维度（流程、功能点）展开了。
使用催化剂方法重新建模极客时间的例子，结构大概是这样：

通过模型可以看到：订阅专栏、送朋友专栏都是通过建立Subscription对象实现的；再配合简单的说明，就可以让业务方理解系统的功能大致是如何被实现的，哪些模型对哪些业务流程有影响。可见展开了业务维度的领域模型完全可以胜任统一语言的功能。

角色-目标-实体法（Role-Goal-Entity）

催化剂方法将角色与交互直接建模到了领域模型中，从业务维度展开的角度讲，的确有很多优点；但从技术上将，也存在难以克服的缺点：交互被直接建模到模型中，那么要怎么关联模型与软件实现呢？是选择性地忽略交互与角色，还是将交互实现成某种特定的组件呢？
如果忽略交互与角色，业务维度又被隐藏了，领域模型也就无法担任统一语言；而如果作为特定组件，交互严格意义上又不是领域逻辑。

“角色-目标-实体法”一定程度上解决了这个矛盾。这种方法不再将流程建模到模型中，而是作为发现领域概念的指代。
“角