05 DDD、事件风暴与企业架构

输入“/”快速插入内容

05 DDD、事件风暴与企业架构

用户5909

用户6566

6月2日修改

📌

设计题优先页：纪要指出 DDD 设计分析题曾作为约 20 分题目；本页把 DDD 的分析框架、企业架构理论题与历年高频问题合并成答题训练清单。​

DDD：先判断是否值得用

脑图：DDD 设计分析题怎么展开

🧠

记忆方法：DDD 题先判断是否需要 DDD，再从问题空间进入解空间，最后落到聚合、事件和重构收益。​

画板

适用场景

•
业务复杂，概念多且规则不断变化。​

•
不同上下文对同一名词含义不同。​

•
需要把业务边界落实为软件边界。​

50%

不宜滥用

•
简单 CRUD、小型低变化系统。​

•
规则很少、引入完整建模成本过高。​

•
只套术语而没有领域专家协作。​

50%

战略设计与战术设计

层面

核心问题

关键元素

电商示例

战略设计

strategic design

业务怎么分边界、怎么集成

子领域、核心域、限界上下文、上下文映射、统一语言

划分订单、库存、支付上下文

战术设计

tactical design

上下文内部怎样实现规则

实体、值对象、聚合、聚合根、领域事件、资源库

订单聚合根维护订单项一致性并发布订单已创建事件

💡

限界上下文是什么：限界上下文（Bounded Context）是 DDD 中给模型划定的语义边界。在这个边界内，同一套领域模型和统一语言保持一致；出了这个边界，同一个词可以有不同含义。​

例子：“课程”在选课上下文里关注容量、时间、先修要求；在支付上下文里可能只是订单商品项；在教学上下文里关注章节、作业和评分。划清限界上下文，就是避免把这些语义硬塞进一个“大一统模型”。​

答题句：限界上下文不是普通代码模块，而是模型和语言的一致性边界；它帮助团队明确业务边界、降低模型歧义，并为服务拆分、上下文映射和集成方式提供依据。​

DDD 实战课补充：从概念到画图答案

📌

补充定位：slides/领域驱动设计项目实战讲解.pdf 更适合补“怎么做、怎么画、怎么把例子写进设计题”。考试答题时仍沿用上面的六步，但可以用本节的研发过程、限界上下文 vs 模块、聚合规则和事件风暴例子把答案写实。​

DDD 研发过程：从问题空间进入解空间

画板

•
问题空间：先让领域专家和开发团队用统一语言（Ubiquitous Language）描述业务，明确业务需求和期望。​

•
战略设计（Strategic Design）：把业务拆成子领域（Subdomain）、限界上下文（Bounded Context），并说明上下文之间怎样集成。​

•
战术设计（Tactical Design）：在单个上下文内部，用实体、值对象、聚合、聚合根、领域事件、资源库、工厂、领域服务表达业务规则。​

•
答题表述：DDD 不是先画代码分层，而是先把业务语义和边界讲清楚，再说明领域模型怎样落到架构与代码。​

限界上下文 vs 模块：一个按业务语义切，一个按技术层次切

画板

模块

•
先按技术维度水平分层，例如页面、业务、持久化。​

•
业务模块往往只是业务层的一部分，不能独立表达完整业务能力。​

•
需求变化时，展现层、业务层和数据层可能一起被牵动。​

50%

限界上下文

•
先按领域维度纵向切分，形成模型和语言的一致性边界。​

•
一个上下文内部可以再按技术关注点分层。​

•
同一个词在不同上下文可以有不同含义，例如 Product 在采购、订单、库存、运输中关注的规则不同。​

50%

📝

例题写法：看到“大一统商品模型字段过多、多个业务都依赖 Product”的题目，可以写：问题不只是类太大，而是没有按知识语境划分限界上下文。应把商品、采购、订单、库存、运输分别放到对应上下文中，让每个上下文只保留自己关心的 Product 概念和规则。​

聚合规则：把一致性边界画出来

画板

DDD 战术概念速查：实体、值对象、事件与不变量

💡

记忆方法：实体看身份，值对象看属性值，聚合看一致性边界，领域事件看已经发生的业务事实，业务不变量看必须始终成立的规则。​

对象怎么分

•
实体（Entity）：有稳定身份，生命周期中属性可以变化，但身份连续。例如 Order 或 Customer，订单状态会变，但订单号代表的订单仍是同一个。​

50%

规则怎么守

•
聚合根（Aggregate Root）：聚合唯一入口和出口，负责检查和维护聚合内部规则。例如 Order 负责添加订单项、计算总价、推进状态。​

50%

05 DDD、事件风暴与企业架构​

05 DDD、事件风暴与企业架构