重庆网站建设是什么,建设数字官方网站,网站邮件系统建设招标,广州黄埔网站建设公司哪家好文章目录 Pre概述业务流程需求分析的困境统一语言建模事件风暴会议什么是事件风暴#xff08;Event Storming#xff09;事件风暴会议 总结 Pre
DDD - 软件退化原因及案例分析
DDD - 如何运用 DDD 进行软件设计
DDD - 如何运用 DDD 进行数据库设计
DDD - 服务、实体与值对… 文章目录 Pre概述业务流程需求分析的困境统一语言建模事件风暴会议什么是事件风暴Event Storming事件风暴会议 总结 Pre
DDD - 软件退化原因及案例分析
DDD - 如何运用 DDD 进行软件设计
DDD - 如何运用 DDD 进行数据库设计
DDD - 服务、实体与值对象的两种设计思路贫血模型与充血模型
DDD - 聚合、聚合根、仓库与工厂
DDD - 问题域和限界上下文 概述
微服务设计最核心的难题是微服务的拆分不合理的微服务拆分不仅不能提高研发效率反倒还使得研发效率更低因此要讲究“小而专”的设计。“小而专”的设计意味着微服务的设计不是简单拆分而是对设计提出了更高的要求要“低耦合、高内聚”。那么如何做到“低耦合、高内聚”实现微服务的“小而专”呢那就需要“领域驱动设计”作为方法论来指导我们的开发。
用“领域驱动设计”是业界普遍认可的解决方案也就是解决微服务如何拆分以及实现微服务的高内聚与单一职责的问题。但是领域驱动设计应当怎样进行呢怎样从需求分析到软件设计用正确的方式一步一步设计微服务呢现在我们用一个在线订餐系统实战演练一下微服务的设计过程。 业务流程
相信我们都使用过在线订餐系统比如美团、大众点评、百度外卖等具体的业务流程如下图所示 在线订餐系统的业务流程图 当我们进入在线订餐系统时首先看到的是各个饭店进入每个饭店都能看到他们的菜单 下单时订单中就会包含我们订的是哪家饭店、菜品、数量及我们自己的配送地址 下单后相应的饭店就会收到该下单系统 接着饭店接单然后开始准备餐食 当饭店的餐食就绪以后通知骑士进行派送 最后骑士完成了餐食的派送订单送达我们就愉悦地收到了订购的美味佳肴。
现在我们要以此为背景按照微服务架构来设计开发一个在线订餐系统。那么我们应当如何从分析理解需求开始一步一步通过前面讲解的领域驱动设计最后落实到拆分微服务把这个系统拆分出来呢
需求分析的困境
软件开发的最大风险是需求分析因为在这个过程中谁都说不清楚能让对方了解的需求。
研发不懂客户、客户也不懂研发
在这个过程中对于客户来说 客户十分清楚他的业务领域知识以及他亟待解决的业务痛点 然而客户不清楚技术能如何解决他的业务痛点。
因此用户在提需求时是在用他有限的认知想象技术如何解决他的业务痛点。所以这样提出的业务需求往往不太靠谱要么技术难于实现要么并非最优的方案。
与此同时在需求分析过程中对于研发人员来说 非常清楚技术以及能解决哪些业务问题同时也清楚它是如何解决的 然而欠缺的是对客户所在的业务领域知识的掌握使得无法准确理解客户的业务痛点。
这就局限了我们的设计进而所做的系统不能完美地解决用户痛点。
因此在需求分析的过程中不论是客户还是我们都不能掌握准确理解需求所需的所有知识这就导致不论是谁都不能准确地理解与描述软件需求。在需求分析中常常会出现客户以为他描述清楚需求了我们也以为我们听清楚了。但当软件开发出来以后客户才发现这并不是他需要的软件而我们也发现我们并没有真正理解需求。尽管如此客户依然没有想清楚他想要什么而我们还是不知道该怎样做这就是软件开发之殇。 统一语言建模
如何能够破解这个困局呢关键的思想就在于“统一语言建模”。也就是说以上问题的根源在于语言沟通的障碍使得我不能理解你而你也不能理解我。因此解决的思路就是 我主动学习你的语言了解你的业务领域知识并用你的语言与你沟通 同时我也主动地让你了解我的语言了解我的业务领域知识并用我的语言与你沟通。
回到需求分析领域我们清楚的是技术但不了解业务因此应当主动地去了解业务。那么如何了解业务呢找书慢慢地去学习业务吗也不是因为我们不是要努力成为业务领域专家而仅仅是要掌握与要开发软件相关的业务领域知识。在业务领域漫无目的地学习学习效率低而收效甚微。
所以我们应当从客户那里去学习比如询问客户仔细聆听客户对业务的描述在与客户的探讨中快速地学习业务。然而在这个过程中一个非常重要的关键就是注意捕获客户在描述业务过程中的那些专用术语努力学会用这些专用术语与客户探讨业务。
久而久之用客户的语言与客户沟通你们的沟通就会越来越顺畅客户也会觉得你越来越专业愿意与你沟通并可以与你探讨越来越深的业务领域知识。当你对业务的理解越来越深刻你就能越来越准确地理解客户的业务及痛点并运用自己的技术专业知识用更加合理的技术去解决用户的痛点。这样你们的软件就会越来越专业让用户能越来越喜欢购买和使用你们的软件并形成长期合作关系。 以一个远程智慧诊疗数据模型为例这是一个面向中医的数据模型。在与客户探讨需求的过程中我们很快发现用户在描述中医的诊疗过程中许多术语与西医有很大的不同。 比如他们在描述患者症状的时候通常不用“症状”这个词而是用“表象”。表象包括症状、体征、检测指标是医生通过不同方式捕获患者病症的所有外部表现同时他们在诊断的时候也不用“疾病”这个词而是“证候”。中医认为证候才是患者疾病在身体中的内部根源抓住证候将证候的问题解决了疾病自然就药到病除了。我们把握了这些术语后用这些术语与业务专家进行沟通沟通就变得异常顺利。客户会觉得我们非常专业很懂他们并且变得异常积极地与我们探讨需求并很快建立了一种长期合作的关系。 同时在这个过程中我们一边在与客户探讨业务领域知识一边又可以让客户参与到我们分析设计的工作中来用客户能够理解的语言让客户清楚我们是如何设计软件的。
这样当客户有参与感以后就会对我们的软件有更强烈的认可度更有利于软件的推广。此外客户参与了并理解我们是怎么做软件的就会逐步形成一种默契。使得客户在日后提需求、探讨需求的时候提出的需求更靠谱避免技术无法实现的需求使得需求质量大幅度得到提高。 事件风暴会议
什么是事件风暴Event Storming
在领域驱动设计之初的需求分析阶段对需求分析的基本思路就是统一语言建模它是我们的指导思想。但落实到具体操作层面可以采用的实践方法是事件风暴Event Storming。它是一种基于工作坊的 DDD 实践方法可以帮助我们快速发现业务领域中正在发生的事件指导领域建模及程序开发. 它是由意大利人 Alberto Brandolini 发明的一种领域驱动设计实践方法被广泛应用于业务流程建模和需求工程。
这个方法的基本思想就是将软件开发人员和领域专家聚集在一起一同讨论、相互学习即统一语言建模。但它的工作方式类似于头脑风暴让建模过程变得更加有趣让学习业务变得更加容易。因此事件风暴中的“风暴”就是运用头脑风暴会议进行领域分析建模。
那么这里的“事件”是什么意思呢事件即事实Event as Fact即在业务领域中那些已经发生的事件就是事实fact。过去已经发生的事件已经成为了事实就不会再更改因此信息管理系统就可以将这些事实以信息的形式存储到数据库中即信息就是一组事实。
说到底一个信息管理系统的作用就是存储这些事实对这些事实进行管理与跟踪进而起到提高工作效率的作用。因此分析一个信息管理系统的业务需求就是准确地抓住业务进行过程中那些需要存储的关键事实并围绕着这些事实进行分析设计、领域建模这就是“事件风暴”的精髓。 事件风暴会议
因此实践“事件风暴”方法就是让开发人员与领域专家坐在一起开事件风暴会议。会议的目的就是与领域专家一起进行领域建模而会议前的准备就是在会场准备一个大大的白板与各色的便笺纸如下图所示 事件风暴会议图
当开始事件风暴会议以后通常分为这样几个步骤。 首先在产品经理的引导下与业务专家开始梳理当前的业务中有哪些领域事件即已经发生并需要保存下来的那些事实。这时是按照业务流程依次去梳理领域事件的。例如在本案例中整个在线订餐过程分为已下单、已接单、已就绪、已派送和已送达这几个领域事件。注意领域事件是已发生的事实因此在命名的时候应当采用过去时态。 这里有一个十分有趣的问题值得探讨。在用户下单之前用户首先是选餐。那么“用户选餐”是不是领域事件呢注意领域事件是那些已经发生并且需要保存的重要事实。这里“用户选餐”仅仅是一个查询操作并不需要数据库保存因此不能算领域事件。那么难道这些查询功能不在需求分析的过程中吗 注意DDD 有自己的适用范围它往往应用于系统增删改的业务场景中而查询场景的分析往往不用 DDD而是通过其他方式进行分析。分析清楚了领域事件以后就用橘黄色便笺纸将所有的领域事件罗列在白板上确保领域中所有事件都已经被覆盖。 紧接着针对每一个领域事件项目组成员开始不断地围绕着它进行业务分析增加各种命令与事件进而思考与之相关的资源、外部系统与时间。例如在本案例中首先分析“已下单”事件分析它触发的命令、与之相关的人与事儿以及发生的时间。命令使用蓝色便笺人和事儿使用黄色便笺如下图所示 “已下单”的领域事件分析图
“已下单”事件触发的命令是“下单”执行者是“用户”画一个小人作为标识执行时间是“下单时间”。与它相关的人和事儿有“饭店”与“订单”。在此基础上进一步分析用户关联到用户地址饭店关联到菜单订单关联到菜品明细。
然后就是识别模型中可能涉及的聚合及其聚合根。所谓的“聚合”就是整体与部分的关系譬如饭店与菜单是否是聚合关系关键看它俩的数据是如何组织的。如果菜单在设计时是独立于饭店之外的如“宫保鸡丁”是独立于饭店的菜单每个饭店都是在引用这条记录那么菜单与饭店就不是聚合关系即使删除了这个饭店这个菜单依然存在。 但如果菜单在设计时每个饭店都有自己独立的菜单譬如同样是“宫保鸡丁”饭店 A 与饭店 B 使用的都是各自不同的记录。这时菜单在设计上就是饭店的一个部分删除饭店就直接删除了它的所有菜单那么菜单与饭店就是聚合关系。在这里那个代表“整体”的就是聚合根所有客户程序都必须要通过聚合根去访问整体中的各个部分。
通过以上分析我们认为用户与地址、饭店与菜单、订单与菜品明细都是聚合关系。如果是聚合关系就在该关系上贴一张紫色便笺。
按照以上步骤一个一个地去分析每个领域事件 在线订餐系统的领域事件分析图
当所有的领域事件都分析完成以后最后再站在全局对整个系统进行模块的划分划分为多个限界上下文并在各个限界上下文之间定义它们的接口规划上下文地图。 总结
按照 DDD 的思想进行微服务设计首先是从需求分析开始的。但 DDD 彻底改变了我们需求分析的方式采用统一语言建模让我们更加主动地理解业务用客户的语言与客户探讨需求。统一语言建模是指导思想事件风暴会议是实践方法。运用事件风暴会议与客户探讨需求、建立模型我们能更加深入地理解需求而客户也更有参与感。此外事件风暴会议可以作为敏捷开发中迭代计划会议前的准备会议的一个部分。
然而通过事件风暴会议形成的领域模型又该如何落地到微服务的设计呢还会遇到哪些设计与技术难题呢
