门户网站建设服务,wordpress 手机浏览器,做网站不买服务器百度能搜到,吉林省建设安全信息网官网文章目录 事件风暴需要准备些什么#xff1f;如何用事件风暴构建领域模型#xff1f; 事件风暴是一项团队活动#xff0c;领域专家与项目团队通过头脑风暴的形式#xff0c;罗列出领域中所有的领域事件#xff0c;整合之后形成最终的领域事件集合#xff0c;然后对每一个… 文章目录 事件风暴需要准备些什么如何用事件风暴构建领域模型 事件风暴是一项团队活动领域专家与项目团队通过头脑风暴的形式罗列出领域中所有的领域事件整合之后形成最终的领域事件集合然后对每一个事件标注出导致该事件的命令再为每一个事件标注出命令发起方的角色。命令可以是用户发起也可以是第三方系统调用或者定时器触发等最后对事件进行分类整理出实体、聚合、聚合根以及限界上下文。而事件风暴正是 DDD 战略设计中经常使用的一种方法它可以快速分析和分解复杂的业务领域完成领域建模。 事件风暴需要准备些什么
事件风暴的参与者
事件风暴采用工作坊的方式将项目团队和领域专家聚集在一起通过可视化、高互动的方式一步一步将领域模型设计出来。领域专家是事件风暴中必不可少的核心参与者。很多公司可能并没有这个角色那我们该寻找什么样的人来担当领域专家呢 领域专家就是对业务或问题域有深刻见解的主题专家他们非常了解业务和系统是怎么做的同时也深刻理解为什么要这样设计。如果你的公司里并没有这个角色那也没关系你可以从业务人员、需求分析人员、产品经理或者在这个领域有多年经验的开发人员里按照这个标准去选择合适的人选。 除了领域专家事件风暴的其他参与者可以是 DDD 专家、架构师、产品经理、项目经理、开发人员和测试人员等项目团队成员。领域建模是统一团队语言的过程因此项目团队应尽早地参与到领域建模中这样才能高效建立起团队的通用语言。到了微服务建设时领域模型也更容易和系统架构保持一致。
事件风暴要准备的材料
事件风暴参与者会将自己的想法和意见写在即时贴上并将贴纸贴在墙上的合适位置我们戏称这个过程是“刷墙”。所以即时贴和水笔是必备材料另外你还可以准备一些胶带或者磁扣以便贴纸随时能更换位置。在这个过程中我们要用不同颜色的贴纸区分领域行为。颜色并不固定这只是我的习惯团队内统一才是重点。
事件风暴的场地
什么样的场地适合做事件风暴呢是不是需要跟组织会议一样准备会议室、投影还有椅子这些都不需要你只需要一堵足够长的墙和足够大的空间就可以了。墙是用来贴纸的大空间可以让人四处走动方便合作。撤掉会议桌和椅子的事件风暴你会发现参与者们的效率更高。事件风暴的发明者曾经建议要准备八米长的墙这样设计就不会受到空间的限制了。当然这个不是必要条件看各自的现实条件吧不要让思维受限就好。
事件风暴分析的关注点
在领域建模的过程中我们需要重点关注这类业务的语言和行为。比如某些业务动作或行为事件是否会触发下一个业务动作这个动作事件的输入和输出是什么是谁实体发出的什么动作命令触发了这个动作事件…我们可以从这些暗藏的词汇中分析出领域模型中的事件、命令和实体等领域对象。
如何用事件风暴构建领域模型
领域建模的过程主要包括产品愿景、业务场景分析、领域建模和微服务拆分与设计这几个重要阶段。以用户中台为例介绍一下如何用事件风暴构建领域模型。
1.产品愿景
产品愿景的主要目的是对产品顶层价值的设计使产品目标用户、核心价值、差异化竞争点等信息达成一致避免产品偏离方向。产品愿景的参与角色领域专家、业务需求方、产品经理、项目经理和开发经理。在建模之前项目团队要思考这样两点 用户中台到底能够做什么它的业务范围、目标用户、核心价值和愿景与其它同类产品的差异和优势在哪里 这个过程也是明确用户中台建设方向和统一团队思想的过程。参与者要对每一个点下图最左侧列的内容发表意见用水笔写在贴纸上贴在黄色贴纸的位置。这个过程会让参与者充分发表意见最后会将发散的意见统一为通用语言建立如下图的产品愿景墙。如果你的团队的产品愿景和目标已经很清晰了那这个步骤你可以忽略。 2.业务场景分析
场景分析是从用户视角出发的根据业务流程或用户旅程采用用例和场景分析探索领域中的典型场景找出领域事件、实体和命令等领域对象支撑领域建模。事件风暴参与者要尽可能地遍历所有业务细节充分发表意见不要遗漏业务要点。场景分析的参与角色领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。用户中台有这样三个典型的业务场景 第一个是系统和岗位设置设置系统中岗位的菜单权限第二个是用户权限配置为用户建立账户和密码设置用户岗位第三个是用户登录系统和权限校验生成用户登录和操作日志。 我们可以按照业务流程一步一步搜寻用户业务流程中的关键领域事件比如岗位已创建用户已创建等事件。再找出什么行为会引起这些领域事件这些行为可能是一个或若干个命令组合在一起产生的比如创建用户时第一个命令是从公司 HR 系统中获取用户信息第二个命令是根据 HR 的员工信息在用户中台创建用户创建完用户后就会产生用户已创建的领域事件。当然这个领域事件可能会触发下一步的操作比如发布到邮件系统通知用户已创建但也可能到此就结束了你需要根据具体情况来分析是否还有下一步的操作。场景分析时会产生很多的命令和领域事件。我用蓝色来表示命令用橙色表示领域事件用黄色表示补充信息比如用户信息数据来源于 HR 系统的说明。
3.领域建模
领域建模时我们会根据场景分析过程中产生的领域对象比如命令、事件等之间关系找出产生命令的实体分析实体之间的依赖关系组成聚合为聚合划定限界上下文建立领域模型以及模型之间的依赖。领域模型利用限界上下文向上可以指导微服务设计通过聚合向下可以指导聚合根、实体和值对象的设计。领域建模的参与角色领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。具体可以分为这样三步。 第一步从命令和事件中提取产生这些行为的实体。用绿色贴纸表示实体。通过分析用户中台的命令和事件等行为数据提取了产生这些行为的用户、账户、认证票据、系统、菜单、岗位和用户日志七个实体。 第二步根据聚合根的管理性质从七个实体中找出聚合根比如用户管理用户相关实体以及值对象系统可以管理与系统相关的菜单等实体等可以找出用户和系统等聚合根。然后根据业务依赖和业务内聚原则将聚合根以及它关联的实体和值对象组合为聚合比如系统和菜单实体可以组合为“系统功能”聚合。按照上述方法用户中台就有了系统功能、岗位、用户信息、用户日志、账户和认证票据六个聚合。第三步划定限界上下文根据上下文语义将聚合归类。根据用户域的上下文语境用户基本信息和用户日志信息这两个聚合共同构成用户信息域分别管理用户基本信息、用户登录和操作日志。认证票据和账户这两个聚合共同构成认证域分别实现不同方式的登录和认证。系统功能和岗位这两个聚合共同构成权限域分别实现系统和菜单管理以及系统的岗位配置。根据业务边界我们可以将用户中台划分为三个限界上下文用户信息、认证和权限。
4.微服务拆分与设计
原则上一个领域模型就可以设计为一个微服务但由于领域建模时只考虑了业务因素没有考虑微服务落地时的技术、团队以及运行环境等非业务因素因此在微服务拆分与设计时我们不能简单地将领域模型作为拆分微服务的唯一标准它只能作为微服务拆分的一个重要依据。微服务的设计还需要考虑服务的粒度、分层、边界划分、依赖关系和集成关系。除了考虑业务职责单一外我们还需要考虑将敏态与稳态业务的分离、非功能性需求如弹性伸缩要求、安全性等要求、团队组织和沟通效率、软件包大小以及技术异构等非业务因素。微服务设计建议参与的角色领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。用户中台微服务设计如果不考虑非业务因素我们完全可以按照领域模型与微服务一对一的关系来设计将用户中台设计为用户、认证和权限三个微服务。但如果用户日志数据量巨大大到需要采用大数据技术来实现这时用户信息聚合与用户日志聚合就会有技术异构。虽然在领域建模时我们将他们放在一个了领域模型内但如果考虑技术异构这两个聚合就不适合放到同一个微服务里了。我们可以以聚合作为拆分单位将用户基本信息管理和用户日志管理拆分为两个技术异构的微服务分别用不同的技术来实现它们。
你知道的越多你不知道的越多。
