事件风暴第四步：识别上下文映射

最新推荐文章于 2025-12-07 03:44:15 发布
原创 最新推荐文章于 2025-12-07 03:44:15 发布 · 411 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本事件风暴系列是参加张逸老师的课程《面向场景的领域驱动设计全过程工作坊》的学习总结。

不作商业用途，仅作交流学习。

通过事件风暴：

  • 首先识别跨限界上下文之间相邻事件的关系
  • 事件之间是否存在直接触发的关系（参与者为前置事件），需要确定这两个事件所述的限界上下文
  • 判断这两个事件所属的限界上下文，谁是主要的。主要的BC就是下游。通常，前置事件为下游，或者是事件的发布者

 

领域驱动设计实战：构建高效的在线请假考勤系统
热门推荐
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
03-27 169万+
领域驱动设计DDD是一种设计思想，它可以同时指导中台业务建模和微服务设计(中台本质是业务模型，微服务是业务模型的系统落地)，领域驱动设计强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。
上下文窗口在AI原生应用中的5大应用场景
AI天才研究院
07-09 849
上下文窗口(Context Window)代表了大型语言模型(LLMs)在生成响应时能够"看到"的输入文本总量限制，通常以tokens为单位计量。这一架构约束源自Transformer模型的自注意力机制计算复杂度(O(n²))与内存限制的权衡，却意外成为塑造AI系统行为与能力边界的关键因素。GPT-4 Turbo (2023)：128k tokens，支持16k输出部分研究模型：已实现1M+ tokens窗口(如LongNet、MemGPT等)
context-mapper-dsl：ContextMapper DSL：用于上下文映射和服务分解的特定于域的语言
02-13
上下文映射器DSL（CML） ContextMapper是一个开放源代码工具，提供基于域驱动设计（DDD）模式的特定于域的语言，用于上下文映射和服务分解。 使用ContextMapper DSL语言，您可以表达DDD上下文映射。 使用该语言对系统建模之后，就可以使用提供的生成器来创建UML图，服务合同，并使用计算服务分解建议。 请访问我们的网站以开始使用。 Context Mapper项目最初是作为研究项目的一部分开发的。 您可以在找到项目报告和更多背景信息。 安装链接：上下文映射器可用于Visual Studio Code和Eclipse： VS代码： 注意：我们只是最近才发布了VS Code扩展，它尚不支持所有功能。 找到功能支持表。 我们一直在致力于扩展，它将很快支持所有功能！ 蚀： 更新站点： : 特征 ContextMapper DSL语言支持（CML文件） 编写
事件风暴第三步：识别限界上下文
宵小小沉的专栏
12-11 710
本事件风暴系列是参加张逸老师的课程《面向场景的领域驱动设计全过程工作坊》的学习总结。 不作商业用途，仅作交流学习。 两个方向 从两个方向识别限界上下文： 纵向：识别事件流中的事件，倘若相邻两个事件之间的关系较弱，或者体现了两个非常明显的阶段，就可以对其进行分割。 横向：梳理所有的事件，根据组成事件的名词和动词去发现事件之间的相关性（相同、相似的名称），然后去提炼一个整体的概念。 两个原则...
uid-generator在大数据场景中的应用：海量数据唯一标识终极指南
最新发布
gitblog_00553的博客
12-07 587
在大数据时代，如何为海量数据生成高效、可靠的唯一标识符成为分布式系统的核心挑战。uid-generator作为一款高性能的分布式唯一ID生成器，通过优化算法和缓存机制，为大数据场景提供了完美的解决方案。 ## 什么是分布式唯一ID生成器？ 分布式唯一ID生成器是在分布式系统中生成全局唯一标识符的工具。传统的数据库自增ID在分布式环境下存在诸多问题，而uid-generator通过创新的设计解决
DDD领域驱动设计-事件风暴
haoxin963的专栏
11-02 2596
事件风暴通过工作坊的形式，由PM、RD、业务各方共同参与的， 发现并对齐领域知识。比较传统的做法是找一面大的白版，使用各种颜色的便签纸填写相关内容，往白板上粘贴。现在也有一些更便捷的支持协作的在线工具可供使用：BeeArt。
DDD建模方法论之【事件风暴法】
u011385940的专栏
05-25 1万+
DDD建模方法论之【事件风暴法】 前言 在领域驱动设计之初的需求分析阶段，对需求分析的基本思路就是统一语言建模，它是我们的指导思想。落实到具体操作层面，可以采用的具体方法是事件风暴法。 统一语言建模 -> 指导思想。 事件风暴会议 -> 实践方法。 事件风暴 事件风暴（Event Storming）： 一种基于工作坊的DDD实践方法，可以快速发现业务领域中正在发生的事件，指导领域建模及程序开发。 事件：即事实，即在业务领域中那些已经发生的事件就是事实。风暴：运用头脑风暴会议进行领.
DDD第3篇 - 事件风暴
yasinshaw的博客
11-27 6654
什么是事件风暴很多人在学习DDD的过程中，都会有一个疑问：DDD的概念看着挺多，听起来也很有用。但具体怎么落地实施到项目中？事件风暴（Event Storming）于2013年首次被提出...
WebCall：丰富上下文的移动研究框架
### WebCall：丰富上下文的移动研究框架 #### 用户注册 用户注册是使用WebCall的第一步。在诺基亚N95手机浏览器中显示的注册页面截图展示了注册的具体界面。为减轻用户在手机上输入文本的负担，在邀请触发的注册...
事件组性能实测报告：响应延迟、内存占用与上下文切换开销数据全公开
其核心思想是通过一个无符号整型变量作为事件集合，每一位代表一个独立事件，支持多事件等待、任意触发或全事件触发等模式，从而降低任务间通信的复杂度。 ```c typedef struct { uint32_t event_flags; // 当前已...
嵌入式CI_CD落地第一步：Git与编译系统集成的4种可行架构解析
[嵌入式CI_CD落地第一步：Git与编译系统集成的4种可行架构解析](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f1bccf73137a4bf39cfd9fe0df14abe6~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp) ...
EventStormingWorkShop：EventStorming工作坊，这是一个动手工作坊。 包含以下主题：DDD，事件风暴，示例规范。 包括AWS产品：无服务器Lambda，DynamoDB，Fargate，CloudWatch
02-01
在AWS上实施域驱动设计（DDD） @ 2019-12-17更新。 非常感谢您的手表和星星，现在这个研讨会已经正式合并为 ，所有未解决的研究和实现也将合并，欢迎继续进行观看并标记新的回购。 。 来自的免费图片许可 构建软件很难。 了解软件的业务需求更加困难。 在几乎每个软件开发项目中，业务用户的需求和实际实施之间总是存在某种形式的差距。 作为开发人员，知道如何缩小这一差距可以帮助您走很长一段路来构建与用户相关的应用程序。 使用通过Event Storming提供的域驱动设计方法，它可以帮助减少项目团队中每个人理解业务域模型所花费的时间。 理论与实践：现实世界中的学习案例 经历所有学习过程，在AWS上开发->构建->部署工件 目录 事件风暴 什么是事件风暴？ Event Storming是一种快速，轻量级且通常未被重视的团队建模技术，它非常激烈，有趣并且对加速项目团队很有用。 它通常以交互式研讨会的形式提供，它是根据“领域驱动设计（DDD）”原理从Gamestorming中促进的小组学习实践的综合。 您可以将其实际应用于任何技术或业务领域，尤其是大型，复杂或两者兼而有之的领域
event-storming-cheatsheet:用于准备和促进事件风暴研讨会的简短备忘单
05-31
事件风暴研讨会备忘单 事件风暴是一种软件系统的快速设计技术，涉及技术人员和领域专家/业务分析师。 它最适合域驱动设计上下文，并倾向于/为事件源和CQRS做准备。 该技术首先由 Alberto Brandolini 引入，并被 Vaughn Vernon 在 Domain Driven Design Distilled 中采用。 它也作为他的 iDDD 研讨会系列的一部分进行教授。 本备忘单旨在为准备和推动Event Storming Workshop提供简短的总结。 它不打算对该主题进行完整的介绍，需要有关 DDD 和事件风暴的先验知识才能负责任地使用本文档。 所需材料 纸卷来创建造型表面。 可在宜家 (Mala, 或亚马逊 ) 购买 粘滞便笺。 Vaughn Vernon 推荐 7,6 x 7,6 厘米的超级粘性品种。 您需要以下颜色：橙色、浅蓝色、淡黄色、绿色、粉色、紫色/红色、淡紫
Event Storming PPT 事件风暴
03-05
COLLABORATIVE LEARNING FOR COMPLEX DOMAINS EventStorming is a workshop format for quickly exploring complex business domains.
捕获需求的利器——领域驱动设计中的事件风暴
重视代码质量也想码到80岁的程序猿笔记
12-28 959
事件风暴抓准了企业软件开发中协作这个痛点，以事件为核心允许不同背景的利益相关方展开对话，并超越各自的专业背景界限，借助白板便利贴重视头脑风暴的可视化，尽可能让所有参与者充分咀嚼领域知识，从而深刻高效地挖掘与传递业务知识，形成业务全景图，减少信息孤岛等偏差存在，有效解决复杂软件的需求分析与传递成本
DDD-事件风暴
分享技术人生的学习笔记和过往心得，与志同道合者共同进步
01-26 1150
事件风暴（Event Storming）是领域驱动设计（DDD）中的一种高度协作的建模方法，旨在通过团队成员的集体讨论和可视化手段，快速理解和探索复杂业务领域。该方法由Alberto Brandolini提出，强调通过全员参与的方式，促进对业务流程的深刻理解，并建立统一的领域模型。
java架构模式与设计模式(四)--事件风暴
秋天的猿
02-21 507
原文地址 目录 什么是事件风暴 事件风暴流程 物料准备 参与人员 寻找领域事件 寻找命令和角色 寻找领域模型和聚合 划分子域和限界上下文 常见的问题 事件的粒度？ 对某个事件有歧义 一个命令产生多个连锁事件 领域模型周围的事件过多 感觉命令就是事件的动词？ 成员完全不熟悉业务怎么办？ 没有领域专家怎么办？ 什么是事件风暴 很多人在学习DDD的过程中，都会有一个疑问：DDD的概念看着挺多，听起来也很有用。但具体怎么落地实施到项目中？ 事件风暴（Event St.
DDD技巧：你知道如何正确使用“事件风暴”来划分领域吗？
surfirst的博客
03-08 1495
本文介绍了组织“事件风暴”的参与人员，准备工作，实施步骤，以及目标成果。和以产品经理带领研发团队研究需求的方式不同，“事件风暴”邀请的是领域专家，聚焦在“业务”领域，而前者聚焦在“实现领域”。“事件风暴”提供了一种跨越“业务”和“开发”的简单的业务研究方法。
复杂的业务，事件风暴驱动DDD也许是良好的解决方案
dotNET跨平台
11-14 347
在微服务架构大行其道的今天，如何有效处理复杂业务系统的领域边界划分始终是一个难题。事件风暴作为领域驱动设计(DDD)中的一项核心实践，它通过业务部门、产品、开发等多方协作的工作坊形式，帮助团队厘清业务流程、统一认知，从而更好地指导微服务架构设计。1. 事件风暴的本质认知传统的需求分析往往陷入细节泥潭，而事件风暴则转换视角，以业务事件为核心，构建起完整的业务场景图景。1.1 核心要素• 领域事件：用...
一个限界上下文就是一个服务吗
06-11
<think>嗯，用户这次的问题集中在限界上下文与微服务的关系上，尤其是两者是否等同的问题。从对话历史看，用户已经研究了事件风暴的操作方法，现在想深入理解其核心输出（限界上下文）如何落地到架构层面。用户提供的四个引用很有价值。引用[1]和[3]强调限界上下文是业务边界的体现，但微服务拆分还需考虑技术因素——这点需要重点展开。引用[2]提到限界上下文可能动态分裂，暗示二者并非静态对应关系。引用[4]则展示了事件驱动架构下，限界上下文如何通过消息队列实现协作，这正好衔接了用户之前学习的事件风暴技术。用户可能是技术负责人或架构师，正面临微服务拆分决策。ta的提问方式显示已经具备DDD基础，但需要更落地的指导。深层需求可能是想确认：是否可以直接把事件风暴工作坊输出的限界上下文映射为微服务。需要澄清三个关键点：第一，限界上下文本质是业务边界，微服务是部署单元；第二，拆分时需补充技术考量；第三，消息队列等机制能解耦不同限界上下文的服务。可以结合电商案例说明“商品”到“货物”的边界变化如何影响服务设计。数学表达方面要特别注意，虽然当前问题不涉及公式，但如果后续讨论一致性哈希等负载均衡算法，需按用户要求的$...$格式书写如$h(key)\modN$。</think> 限界上下文（Bounded Context）与微服务并非严格等同，二者是**业务边界与架构实现的映射关系**。核心区别与关联如下： --- ### **一、限界上下文 ≠ 微服务（关键区别）** | **维度** | 限界上下文 | 微服务 | |----------------|----------------------------|---------------------------| | **本质** | **业务语义边界**（领域模型的自治单元） | **系统部署单元**（独立进程的可执行组件） | | **设计目标** | 解决业务概念一致性（如商品在销售/运输环节的不同语义）[^3] | 实现技术独立性（数据库、技术栈自治） | | **变更驱动** | 业务需求变化导致模型重构 | 性能、团队拆分、技术异构等非功能需求 | > 示例：电商系统中 > - **限界上下文**： `商品销售上下文`（含价格、促销规则） vs `物流运输上下文`（含货物重量、配送路径）[^3] > - **微服务实现**：可能因性能需要将两个上下文合并为一个服务（如初创团队资源有限时），或将一个上下文拆分为多个服务（如库存服务独立应对高并发）[^1] --- ### **二、限界上下文 → 微服务的映射规则** #### 1. **理想情况下的1:1映射** 当满足以下条件时，限界上下文可直接对应一个微服务： ```mermaid graph LR A[商品销售限界上下文] --> B(商品微服务) C[物流运输限界上下文] --> D(物流微服务) ``` - **前提**： - 团队能力可独立维护该上下文 - 无跨上下文高频调用（避免分布式事务） - 技术栈允许独立部署[^1][^2] #### 2. **非等同场景** | **场景** | 原因 | 案例 | |-------------------------|------------------------------|--------------------------| | 1个上下文 → N个微服务 | 模型过大需水平拆分（如订单模块拆分为创建/支付/履约服务） | 单团队无法交付整个上下文[^2] | | N个上下文 → 1个微服务 | 降低分布式复杂度（如促销+库存合并） | 初创系统快速验证业务[^1] | --- ### **三、事件风暴中限界上下文的设计关键** 1. **业务语义优先** - 基于术语差异划分边界（如商品→货物）[^3] - 用**棕色胶带**在事件流中标记聚合根边界 2. **动态演进原则** - 初始可粗粒度划分（如合并支付+订单） - 待业务膨胀后再拆分（如支付独立为金融平台）[^2] 3. **架构衔接机制** - 上下文间采用**事件驱动**（如物流订阅订单创建事件） - 通过消息队列（如Kafka）实现解耦[^4] > 示例流程： > $$ > \text{订单微服务} \xrightarrow{\text{发布OrderCreated事件}} \text{Kafka} \xrightarrow{\text{订阅事件}} \text{物流微服务} > $$ --- ### **四、实践建议** 1. **技术约束决策树**： ```mermaid graph TD A[限界上下文确定] --> B{是否需独立技术栈?} B -->|是| C[拆分为独立微服务] B -->|否| D{是否高频跨域调用?} D -->|是| E[合并为单体或宏服务] D -->|否| F[维持1:1映射] ``` 2. **演进路径**： **事件风暴模型 → 限界上下文 → 技术可行性分析 → 微服务拆分** --- **限界上下文与微服务的关系总结**： > 限界上下文是**业务领域的自治岛**，微服务是**技术实现的承载船**。岛的数量由地理（业务）决定，船的部署由航海条件（技术）决定[^1][^2][^4]。 --- **相关问题**： 1. 如何识别限界上下文之间的上下文映射（Context Mapping）关系？ 2. 微服务合并多个限界上下文时如何保证领域模型纯净？ 3. 事件驱动架构（EDA）下领域事件如何设计幂等性？ 4. 团队结构如何与限界上下文对齐？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值