极客时间《如何落地业务建模》学习笔记 09，题图来自极客时间专栏

08 | 什么办法可以在讨论中自然形成统一语言？

事件建模法（Event-based modeling）通过事件捕捉系统中信息的改变，再发掘触发这些改变的源头，然后通过这些源头发现背后参与的实体与操作，最终完成对系统的建模

如何通过对象模型表达流程

模型偏重于数据角度，描述在不同业务维度下，数据将会如何改变，以及如何支撑应对的计算与统计。

业务维度中的流程、交互、功能点，则更关注行为。

采用行为视角和数据视角来分别看待事件和行为，确实更加清楚。

绿地项目 Greenfield 的说法很有意思，对应的似乎有棕地项目 Brownfield，都比较形象。绿地项目是指从头开始的项目，而棕地项目一般是半途接手的存量项目。

• 通过事件表示交互

• 通过时间线划分不同事件

交互事件：通过交互流程产生的事件

领域事件：发生在领域中且值得注意的时间，通常有领域对象状态的改变

领域逻辑的等价接口，这个领域时间的判断方法看起来似乎有些晦涩。

事件风暴法 Event Storming 似乎在敏捷开发领域更加流行一些，而且似乎操作起来也更容易一些，毕竟头脑风暴的方式更随意一些。

感觉事件风暴法和事件建模法似乎在底层都是一样的，都是以事件为中心。

• 事件的命名：名词+动词被动式

• 命令的命名：动词+名词

• 策略的命名：对应的业务逻辑命名

事件风暴法推荐使用 7 种不同的颜色，不知道 3M 便条纸有没有这么多种色彩。

老师在之前的回复中提到 CQRS 似乎不怎么实用。写入数据 Command 和查询数据 Query 分别使用不同的模型可能效果更好。

这个事件风暴法的例子看起来还是比较过瘾的。

简单梳理了一下图中的颜色，其中有一两个颜色稍微有点对不上

七种颜色似乎有些多了。