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

我又想了一下，对于各种类型的系统，只要能找出可追溯的东西，比如钱的流向。再总结出一个合适的分析套路，就能形成一个这种类型的系统的分析方法

事件风暴是一种团队协作方式，通过还原系统的运行轨迹发现关键的领域概念，而事件的发生顺序就是对系统行为的追溯。所以是不是凡是可追溯的东西，都能作为展开的维度？ 事件和阅读模型的关系，事件是发生了一个动作的标志，这个动作还会影响系统，进而产生数据。阅读模型的一个功能就是这种数据的外在表现

对领域事件有疑问，在例子中content requested、content viewed看着都是个交互事件，而非领域事件，这样在事件风暴寻找领域事件应该如何去理解？

“Place Order-Order Placed 产生的阅读模型是订单（Order），Pay Order-Order Paid 产生的阅读模型是订阅（Subscription）和支付（Payment）。” 这个推导过程跨度有点大，这个阅读模型具体是怎么推导出来的呢？

对于策略类（内核架构）的系统，怎么来分析新需求呢？有没有规范化的套路，老师有什么好的建议吗？

本章理解 1.事件意味着一种因果关系，这就使得一个静态的概念，却具备流动的张力。在识别和理解事件时，可以考虑为什么要产生这一事件，以及有什么要响应这一事件，进而思考推出产生事件的前序动作以及响应事件的后续动作，从而驱动参与者的“心流”不断思考下去，不断展开沟通。 2.应用事件不产生数据，领域事件产生数据。会产生数据的事件往往都是关键事件，而这些关键事件背后往往隐藏着我们需要构建的领域模型，这就是通过事件流梳理出领域模型的基本思路。换句话说，领域模型意味着关键事件的留存。 3.事件风暴定义了七个概念，来约束沟通时的表达方式。有利于更清晰的与业务方达成共识。这七个概念不仅有业务视角的概念也有实现视角的概念。比如，站在业务视角，用户执行了决策命令触发了事件。站在实现视角，是聚合履行了发布事件的职责，实现了功能。 课后题： 1.事件的表现形式只能是事件吗？这个问题有点模糊，回答不了。 2.既有事件又存在阅读模型不是一种冗余吗？ 不是，至少存在阅读模型的概念更有利于沟通。 3.除了“事件 - 响应”外，还有什么办法可以展开维度？事件除了作为因，也可作为果。比如为什么要产生这个事件，怎么产生这个事件;比如这个事件留存了什么，留存的东西应该是什么样的，怎么定义它。

事件事件记录的就是各种应该被记录的单据，有点像业务的操作日志。对对象状态变化，一种是修改对象，产生日志；一种是创建日志，进而推出状态变化。事件我觉得是记录了操作日志。

“阅读模型是包含写入与查询的所有数据形态的总集，而聚合只是阅读模型中符合对象风格的子集”这句话的意思是：阅读模型=聚合+查询数据、聚合=写入数据+查询查询，对吗？

想请教下，关于这一篇文件的插图是用什么软件绘制的

订单上下文是以buyer聚合的， 必须要这样聚合吗？ 如果直接访问订单呢？ 这个聚合根的选择有什么方法没