如何开事件风暴会议 2021-09-04 程序之旅,记录 暂无评论 614 次阅读 ## 如何开事件风暴会议 微服务设计最核心的难题是`微服务拆分`，要讲究“小而专”的设计，要“低耦合、高内聚”。这里以在线订餐系统项目来进行实战邻域模型设计。  ### 统一语言建模 软件开发的最多风险是需求分析，因为在这个过程中，没有人能说明白能让对方了解的需求。 在客户方面，他们熟悉业务邻域知识和以及他们急需解决的业务痛点，然而客户并不知道技术该如何解决他们的业务痛点，因此客户是在他的认知范围内去想象技术是如何解决他们的业务痛点，所以他们提出的业务需求往往不太靠谱，要么技术难于实现，要么不是最优方案。 与此同时，研发人员熟悉技术以及技术能解决什么问题，然而，研发人员欠缺的是业务知识的掌握，无法准确的理解客户痛点，进而所做的系统不能完美的解决业务痛点。 因为客户不能理解研发人员，研发人员不能理解客户，出现了沟通障碍。为了解决这个困境，首先我们要主动学习你的语言，了解你的业务邻域知识，并用你的语言与你沟通。从客户那里学习，注意捕获客户在描述业务过程中的那些专业术语，努力学会用这些专用术语与客户探讨业务。 > 在需求分析之初，就是与客户统一语言建模 ### 事件风暴(Event Storming) 一种基于工作坊的 DDD 实践方法，可以快速发现业务领域中正在发生的时间，知道邻域建模及程序开发。 > 事件即事实（Event as Fact），即在业务邻域中那些已经发生的事件就是事实（face） 在产品经理的指导下，与业务专家开始梳理当前的业务中有哪些邻域事件，并按照业务流程进行展开。例如在线订餐系统项目有，已下单、已接单、已就绪、已派送和已送达这几个领域事件，把领域事件使用橘黄色进行标记。 > 邻域事件是已发生的事实，在命名的时候应当采用过去时态。 > > 邻域事件是已经发生并且要保存的事实，例如用户选餐，它是一个查询的操作，并不需要数据库保存，因此不算邻域事件。 针对每一个邻域事件，项目组成员围绕它进行业务分析，增加各种命令与事件，进而思考与之相关的资源、外部系统与时间。命令使用蓝色标记，人和事使用黄色标记。如下图：  之后就是识别模型中可能涉及的聚合及其聚合根，如果是聚合关系，在关系中贴上紫色标识。例如： 饭店与菜单是否是聚合关系 - 如果菜单在设计时是独立于饭店之外的，那么菜单与饭店就不是聚合关系。 - 如果菜单在设计时，每个饭店都有自己独立的菜单，那么菜单与饭店是聚合关系。 > 在整个系统中，所有客户程序都必须通过聚合根来访问整体中的各个部分。  打赏: 微信, 支付宝 标签: DDD, 邻域模型 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
微信
支付宝