灵璧网站建设,防红链接在线生成,wordpress 中国地图,网站建设专题在确定了全景事件流之后#xff0c;可以在战略设计层面继续精进#xff0c;鉴别出领域与限界上下文的边界#xff0c;进入战术设计阶段的领域分析建模。
事件风暴的分析模型要素
通过事件风暴进行领域分析建模#xff0c;其核心的模型要素就是“事件”。除此之外#xf…在确定了全景事件流之后可以在战略设计层面继续精进鉴别出领域与限界上下文的边界进入战术设计阶段的领域分析建模。
事件风暴的分析模型要素
通过事件风暴进行领域分析建模其核心的模型要素就是“事件”。除此之外参与事件风暴的分析模型要素还包括决策命令、读模型、策略和聚合。其中事件和策略已经在探索业务全景的时候进行了初步识别。
决策命令
通观事件之起因除了外部系统是直接发布事件之外无论是用户活动还是满足某个条件都需要一个命令Command来响应它才是直接导致事件发生的“因”。在事件风暴中Alberto Brandolini 将命令称之为“决策命令Decision Command”使用浅蓝色即时贴表示。决策命令往往由动宾短语组成例如 Place Order、Send Invitation 等。
由于决策命令和事件存在因果关系因此二者往往是一一对应的。例如Cancel Order 决策命令会触发 OrderCancelled 事件Subscribe Course 决策命令会触发 CourseSubscribed 事件。正是这种一一对应关系使得它们存在语义上的重叠区别仅在于时态。故而有的事件风暴实践者认为可以在事件风暴中省略决策命令。我并不敢苟同这一观点相反我反而极为强调决策命令在事件风暴中的重要性它是领域分析建模的一个重要驱动力因为通过它连接了用户、策略、聚合、读模型和事件如下图所示 从图中可以看出由事件可以驱动出决策命令在它们之间借由聚合对象来发布事件。当事件发生后如果某个策略满足条件也会引发决策命令而用户在引发决策命令时需要足够的读模型来帮助它做出正确的决策。
那么该如何正确地理解决策命令显然Alberto Brandolini 使用决策来修饰命令并非空穴来风因为这一名词突出了命令往往需要更多的信息来帮助参与者Actor做出决策。参与者是用例图的设计要素在事件风暴中可以认为是对所有事件起因的抽象用户、条件满足如定时器与外部系统。其中外部系统对我们而言是一个黑盒子不用考虑它是如何触发了事件因而可以忽略。因此参与者在基于业务场景做出决策时需要如下两方面数据的支撑
信息必须基于足够充分的信息才能做出正确的决策提供这些信息的对象被称之为读模型Read Model在事件风暴中用浅绿色即时贴表示。策略根据业务规则当某个条件满足时会触发一个决策命令这个业务规则被命名为策略Policy在事件风暴中用紫色标签表示。
读模型和策略
当决策命令由用户引发时可以确认该决策命令的发生是否需要提供足够的读模型信息。读模型是用户通过查询读操作获得的。若不具备这一信息可能不足以支持用户执行决策命令。例如买家希望提交订单就需要先查看购物车获得购物车内容然后才能执行下订单Place Order的决策命令触发 OrderCreated 事件。这时查看购物车获得的结果 ShoppingCart 就是读模型 读模型是用户执行决策命令必需的输入信息在代码层面这些读模型就是执行决策命令的领域行为所需的输入参数。用户发起决策命令的方式是因为执行了某个活动例如决策命令“提交订单”实则是因为用户点击了“提交订单”按钮。用户活动的执行与用户体验User eXerperienceUX直接有关。现实世界的业务场景通过用户体验将用户与读模型结合起来把信息传输给事件风暴的决策命令。这一过程牵涉到用户、查询和命令操作恰好符合组成用例的要素。若建模人员熟悉用例也可借助用例图来分析。
注意上图是将读模型 ShoppingCart 提供给 Place Order 决策命令而非查询操作与命令操作之间的交互。有的事件风暴实践者将查询操作也纳入到事件风暴的模型中认为是用户执行查询操作获得读模型后触发了决策命令如下图所示 我认为这样的模型设计并不恰当因为它将活动流程图与事件的因果关系混为一谈了。实际上活动流程图反应了现实世界的问题域事件风暴表现的事件因果关系却是解决方案域的内容这是领域建模活动中两个不同的层次。买家先查询购物车然后提交订单这是买家的操作流程。但从事件的因果关系看并非“查询购物车”触发了“提交订单”这个决策命令而是用户通过查询获得了购物车读模型之后由用户发起“提交订单”的决策命令再通过订单聚合发布了 OrderCreated 事件。“查询购物车”和“提交订单”是两个不同的用户活动它们并不具有时序上的连续性可以认为是两个独立的业务场景。由于查询操作并不会触发事件的发生从模型上看它也不会导致命令的发生因而在事件风暴中并没有查询操作的位置而是以读模型的形式出现。这也变相地促使建模人员在识别用户活动时需要分辨该活动究竟是查询还是命令有利于 CQRS 模式的落地。
当决策命令由策略引发时就表示事件发生后某些数据满足了某条业务规则。一旦该策略被满足就会引起目标对象的状态变更然后根据业务规则的规定触发下一个决策命令。例如策略“提交订单后一旦超过规定时间未支付则取消订单”会触发 Cancel Order 命令从而引起 OrderCancelled 事件的发生。策略引发的决策可以是自动的如定时器检测到支付时间超时也可以是用户手动触发如用户登录时输入错误密码的次数太多还可以二者并存如在取消订单业务场景中Cancel Order 命令既可以由定时器自动触发也可以由用户手动触发。
聚合
虽然决策命令和事件之间存在因果关系但事件并非直接由决策命令发布而是借助一个“媒介”来发布事件。这个媒介就是“聚合Aggregate”。聚合在事件风暴中使用黄色大即时贴来表示。聚合划分了现实世界和模型世界之间的界线。在现实世界是用户执行了决策命令触发了事件在模型世界是聚合履行了发布事件的职责。例如在电商系统的业务流程中现实世界的用户活动是用户提交了订单在模型世界是 Order 聚合发布了 OrderCreated 事件。
寻找聚合的过程可能是一个艰难的过程。由于聚合是构成领域分析模型的核心要素识别聚合需要审慎不要轻易下结论。若未寻找到它可以先贴上一个空白的黄色大即时贴表示这里存在一个聚合但目前还不知道它的名字。
在事件风暴中我们也可以利用事件来反向寻找聚合。分析事件的特征由于它是由决策命令触发的意味着事件的产生会带来目标对象状态的变化。状态的变化分为三种形式
从无到有意味着创建例如“订单已创建”事件标志着新订单的产生。修改属性值意味着值的更新例如“订单已取消”事件使得订单从之前的状态变更为“已取消”状态也可能意味着内容的变化例如“商品被加入到购物车”事件说明购物车增加了一个新的条目。从有到无意味着删除不过在多数项目中并不存在这种状态变化表面是删除实际是修改属性值。例如“会员已注销”事件和“商品已下架”事件实则都不是直接删除会员和商品记录而是将该记录的状态置为“已注销/已下架”状态。
显然发生状态变更的对象有很大几率就是我们要寻找的聚合对象。毕竟聚合对象承担了发布事件的职责而事件又是由于状态变更而产生。谁能准确地侦知状态是否变更以及何时发生变更我想只有拥有状态的聚合对象自身才具备这一能力。
事件风暴的领域分析建模过程
显然围绕着“事件”为中心事件风暴给出了一条有章可循的领域分析建模路径。领域分析建模的基础是探索业务全景的产出物即业已识别出来的事件流以及参与事件流的用户、策略与外部系统。整个领域分析建模的过程如下
第一步挑选任意一个与用户有关的事件反向驱动出决策命令该用户就是发出决策命令的人角色。从事件驱动出决策命令非常容易就是将事件的过去时态转换为动宾形式的决策命令即可。第二步根据决策命令与事件之间的因果关系推导出要发布该事件必须的前置信息即决策所需的读模型。读模型通常由用户通过查询操作获得可以理解为是决策命令行为的输入参数。第三步根据事件状态变更的目标决定决策命令与事件之间的聚合对象。若无法确定则保留一个空的黄色即时贴待以后确定。第四步选择当前事件的后置事件。若后置事件仍然与用户有关则重复第一步若后置事件与外部系统有关可以跳过该事件的建模继续选择下一个后置事件。若事件与策略有关在进一步细化策略对象之后驱动出决策命令重复第三步。
以前面所示的信用卡开卡事件流为例我们依次选择以下三个事件 首先是审批人参与的“开卡申请已审批”事件执行第一步由该事件可以反向驱动出决策命令“审批开卡申请”。第二步是根据决策命令推导出触发事件需要的读模型。审批开卡申请的前置信息是“申请”和“用户征信”若缺乏这两个信息审批人无法做出“审批开卡申请”的决策。第三步是确定决策命令与事件之间的聚合对象。显然“开卡申请已审批”事件影响到的就是申请的状态它就是我们要寻找的聚合对象 接着进入第四步选择下一个后置事件“卡号已生成”。该事件与策略有关细化策略为“卡号规则”。由事件驱动出决策命令为“生成卡号”进入第三步识别两者之间的聚合对象。卡号的生成影响了信用卡的属性可以认为该事件影响状态的目标对象为“信用卡” 继续第四步选择下一个后置事件“信用卡制作完毕”。由于该事件由外部系统发布可以忽略该建模过程仅仅标记外部系统即可 通过这个简单案例可以清晰地看到我总结的领域分析建模过程具有一定的可操作性。事件风暴工作坊的参与人员可以按照建模步骤一步一步执行。执行每一步都需要团队与领域专家进一步讨论和确认保证识别出来的模型对象遵循该领域的统一语言。在这个分析建模过程中每个模型对象都有着建模的参考依据包括模型对象的身份特征、彼此之间的关系、承担的职责这就在一定程度上减轻了对建模人员经验的依赖。
事件风暴的两个层次恰好可以对应领域驱动设计的战略阶段与战术阶段。前者主要用于识别限界上下文后者主要用于建立领域分析模型这恰恰填补了 Eric Evans《领域驱动设计》书中的关键空白。当然Alberto Brandolini 提出的事件风暴不仅于此它还能用于企业的流程改进、业务创新和对新型服务的探索
