软件架构设计

DDD、事件风暴与企业架构

· heleyang
软件架构设计 期末复习
目录

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

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

# DDD：先判断是否值得用

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

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

# 适用场景

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

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

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

# 不宜滥用

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

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

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

# 战略设计与战术设计

层面 核心问题 关键元素 电商示例
战略设计
strategic design		 业务怎么分边界、怎么集成 子领域、核心域、限界上下文、上下文映射、统一语言 划分订单、库存、支付上下文
战术设计
tactical design		 上下文内部怎样实现规则 实体、值对象、聚合、聚合根、领域事件、资源库 订单聚合根维护订单项一致性并发布订单已创建事件

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

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

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

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

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

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

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

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

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

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

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

# 模块

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

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

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

# 限界上下文

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

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

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

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

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

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

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

# 对象怎么分

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

  • **值对象（Value Object）：**没有独立身份，用一组属性值表达概念，通常不可变。例如 Money、Address、OrderId；两个值对象属性相同，就可以视为同一个值。

  • **聚合（Aggregate）：**把一组实体和值对象组织成一致性单元，外部通过聚合根访问，避免对象之间随意互相引用。

# 规则怎么守

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

  • **业务不变量（Business Invariant）：**系统必须始终保证成立的业务规则。例如订单总价必须等于订单项金额之和，已支付订单不能直接删除，库存不能被扣成负数。

  • **领域事件（Domain Event）：**已经发生且业务关心的事实，通常用过去式命名。例如 OrderCreated、OrderPaid、InventoryDeducted；可用于触发跨上下文协作。

**答题表述：**战术建模不是把类改名成 Entity 或 Service，而是先识别哪些对象有身份、哪些只是值，哪些规则必须由聚合根保护，再用领域事件表达跨对象或跨上下文的业务变化。

知识出处：slides/领域驱动设计项目实战讲解.pdf 的 DDD 核心模式、聚合结构与事件风暴部分；对应 OCR：sources/slides-ocr/2026-05-27/pdftotext-triage/领域驱动设计项目实战讲解.txt:142-176, 380-430, 1347-1380。其中“业务不变量”是对聚合根维护一致性规则的答题化表述。

  • 聚合（Aggregate）是领域模型的概念边界，把一组相关实体和值对象封装成一致性单元。

  • **聚合根（Aggregate Root）**是聚合唯一入口和出口，外部对象不应绕过聚合根直接修改内部对象。

  • 聚合之间尽量通过聚合根标识或领域事件协作，避免对象引用互相缠绕。

  • **答题表述：**引入聚合是为了减少领域对象数量和依赖关系带来的复杂度，把业务不变量集中到聚合根维护，避免贫血模型。

# 事件风暴例子：为学课堂怎么从事件走到模型

  1. **先找领域事件：**事件是已经发生的业务事实，命名通常用过去式，例如“订单已提交”“课程名额已锁定”。

  2. **再找参与者：**角色、策略、外部系统、前置事件都可能驱动事件发生。

  3. **再找命令和聚合：**一个事件通常只对应一个聚合；如果出现多个写模型，要检查是否遗漏事件或聚合边界不清。

  4. **最后归属读模型：**读模型要说明属于哪个限界上下文；如果不是当前上下文，就用遵奉者、自己的读模型或 ID 值对象建立关联。

知识出处：slides/领域驱动设计项目实战讲解.pdf；对应 OCR：sources/slides-ocr/2026-05-27/pdftotext-triage/领域驱动设计项目实战讲解.txt:52-88, 123-176, 380-430, 526-620, 617-762, 768-840, 930-1010, 1315-1463, 1465-1640。

# DDD 设计题答题模板

**统一表述：**本页所有 DDD 设计题统一按下面 6 步组织答案；案例、真题和贫血模型解释只是在这个模板上替换业务素材，不再单独定义另一套流程。

**常见判断：**贫血模型只存数据、行为全堆在服务层；DDD 倾向让核心业务行为回到聚合/领域对象，并以聚合根保护一致性。

**贫血模型是什么：贫血模型（Anemic Domain Model）**指领域对象只有数据字段和 getter/setter，几乎没有业务行为；真正的业务规则都堆在 Service、Manager 或脚本里。它看起来有很多“对象”，但对象本身不负责业务，只像数据库表的一层包装。

更容易懂的例子：如果 Order 只保存订单号、金额、状态，而“能不能取消订单”“支付后如何改状态”“订单项金额是否一致”都写在 OrderService 里，那么 Order 就偏贫血。DDD 更希望把订单相关的不变量和行为放回 Order 聚合根中，由它保护一致性。

**为什么不好：**业务规则分散在服务层，容易重复、遗漏或绕过对象边界；对象不能自我保护，一改需求就要到处找逻辑。答设计题时不要另起一套步骤，应回到上方统一六步：先说明适用性与痛点，再统一语言与事件，划定限界上下文，识别聚合根和业务不变量，安排协作落地，最后说明收益与代价。

补充事实源：美团技术团队｜DDD在大众点评交易系统演进中的应用 用大众点评交易系统实践说明：当业务逻辑都堆在 Service 中时，Domain Object 会退化为只承载数据的贫血模型；DDD 更强调把业务行为放回领域对象，并通过限界上下文、上下文映射等方式组织模型边界。

腾讯云开发者｜DDD的宏观架构模式 可作为 DDD 宏观概念补充入口，用于复习 Bounded Context、Context Map 与 Layers 等结构化概念。使用边界：两篇均为工程实践/技术文章，补充说明 DDD 落地，不替代老师纪要、原始 slides 与本地回忆题。

# DDD 设计题例题：两篇外部案例怎么套统一模板

**套用规则：**下面两个例题都按上方“适用性与痛点 → 统一语言与事件 → 限界上下文与上下文映射 → 战术建模 → 协作与落地 → 收益与代价”展开；区别只在案例素材，不再重复发明步骤。

# 例题一：美团抽奖/交易系统实践型 DDD 设计题

**题目示例：**某互联网业务从简单 CRUD 演化为复杂交易/抽奖系统，订单、评价、支付、库存、风控、奖品发放等逻辑互相耦合，大量业务规则堆在 Service 中，领域对象只保存数据。请用 DDD 思路进行架构改进。

  1. 适用性与痛点：业务已经从简单 CRUD 进入复杂规则组合场景；Service 层承担过多业务规则，领域对象退化为贫血模型，修改评价、支付或风控逻辑时容易影响核心交易路径。

  2. **统一语言与事件：**围绕业务方和开发方共同理解的词汇建模，例如抽奖活动、奖池、奖品、用户群体、活动准入、库存、计数、风控、发券；事件可命名为“用户已中奖”“奖品库存已扣减”。

  3. 限界上下文与上下文映射：按业务语义而不是技术分层拆分，可划为抽奖上下文、活动准入上下文、库存上下文、风控上下文、计数上下文等；对券码、平台券等外部系统使用**防腐层（ACL）**隔离外部模型。

  4. **战术建模：**在抽奖上下文中识别实体、值对象和聚合根。例如奖池可作为承载抽奖规则的领域对象，抽奖概率选择、奖品可用性校验等核心规则回到聚合/领域对象中。

  5. **协作与落地：**应用服务编排“参与抽奖”用例，领域对象完成规则判断，Repository 隔离库存和活动数据持久化，领域事件触发发券、通知或计数更新。

  6. **收益与代价：**收益是业务边界更清晰，复杂规则不再散落，系统能按上下文独立演进；代价是前期建模和跨团队语言对齐成本更高，需要持续校正模型。

# 例题二：腾讯云 DDD 概念框架型设计题

**题目示例：**给定一个复杂业务系统，请说明如何用 DDD 从业务概念出发完成领域建模，并解释分层架构/六边形架构如何支撑领域模型落地。

  1. **适用性与痛点：**先判断业务是否足够复杂：规则变化快、概念多、团队沟通成本高、数据库表或技术框架已经不能清楚表达业务知识。

  2. **统一语言与事件：**开发人员与领域专家围绕同一组业务词汇沟通，并让这些词汇进入模型、接口和代码命名；用领域事件表达已经发生的业务事实。

  3. **限界上下文与上下文映射：**一个大领域中不同子问题可能有不同模型，同一个词在不同上下文中含义可能不同；因此要为模型划边界，并用上下文映射说明上下游关系。

  4. 战术建模：在每个上下文内部识别实体、值对象、聚合、聚合根和领域事件。实体强调身份连续性，值对象强调属性值，聚合根负责保护一致性边界。

  5. **协作与落地：**可用分层架构或六边形架构保护领域层：应用层编排用例，领域层放核心规则，基础设施层处理数据库、消息、外部服务等技术细节，并通过依赖倒置避免领域模型依赖框架。

  6. **收益与代价：**统一语言降低沟通歧义，限界上下文控制模型边界，聚合根保护一致性，架构分层保护领域规则；代价是需要持续建模和维护边界。

**考场迁移句：**美团例子适合回答“复杂业务如何从贫血模型走向领域模型”；腾讯云例子适合回答“DDD 设计题应该按哪些概念与架构层次组织答案”。两者都必须回到上方统一六步。

# 事件风暴简记

# 事件风暴图例速查：贴纸代表什么

一句话：事件风暴（Event Storming）先用领域事件把业务事实按时间排出来，再补充谁触发、为什么触发、影响哪个写模型和读模型，最后用聚类帮助发现聚合与限界上下文。

# 主线建模元素

  • **事件（Event）：**已经发生的业务事实，通常放在时间轴主线上，例如“订单已提交”“支付已完成”。

  • **决策 / 命令（Decision / Command）：**触发事件的意图或动作，用来说明“为什么会发生这个事件”。

  • **读模型（Read Model）：**查询或展示所需的数据视图，答题时要说明它属于哪个限界上下文。

  • **聚合（Aggregate）：**处理命令、保护业务不变量的写模型边界；一个事件通常对应一个主要聚合。

# 发现与边界元素

  • **角色（Role）：**触发事件的人或业务参与者。

  • **热点（HotSpot）：**有分歧、暂不处理、需要强调或风险较高的事件/规则。

  • **策略（Policy）：**触发事件的业务规则；可理解为“规则 + 触发时机”。

  • **外部系统（External System）：**事件流中需要交互但不属于当前领域的系统。

  • **前置事件（Previous Event）：**驱动当前事件发生的上游业务事实。

  • **限界上下文（Bounded Context）：**把一簇语义一致、变化原因相近的事件和模型圈成边界。

  1. 画图顺序：先排事件时间轴，再补角色 / 策略 / 外部系统 / 前置事件，然后标出热点，最后从命令 → 聚合 → 读模型 → 限界上下文收束到领域设计。

  2. **答题表述：**事件风暴不是消息队列设计图，而是 DDD 的协作建模方法；它帮助团队统一语言、暴露争议点，并把业务事件逐步转化为聚合、读模型和上下文边界。

**知识出处：**用户提供的“事件风暴图例”截图；对应本地 OCR：sources/slides-ocr/2026-05-27/pdftotext-triage/领域驱动设计项目实战讲解.txt:1315-1328, 1347-1380, 1419-1458。

步骤 结果
识别领域事件 形成按时间排序的业务事实流
标注参与者、命令与规则 明确是谁为何触发变化
聚类事件与热点 发现限界上下文与争议点
识别聚合与读模型 进入可实现的领域设计

# 事件风暴画板：从业务事实到上下文边界

出处精确到本地资料：

  • 复习课纪要：sources/supplemental/2026-05-28/recording-review/软件体系结构复习课录音整理版.md:163-175。该段标题为“领域驱动设计、事件风暴与 AI 赋能 DDD（01:41:35-01:45:39）”，说明 DDD 从问题空间到解空间，事件风暴要识别领域事件、按时间轴梳理事件、识别参与者/策略/外部系统/前置事件，再划分聚合与限界上下文，并区分读模型和写模型。

  • 原始 slides：sources/slides-ocr/2026-05-27/pdftotext-triage/11-12Domain-Driven_Design_-_Event_Storming.txt:1462-1469。该处明确写有“通过事件风暴开展领域建模”，并在图例中列出事件、命令、决策、读模型、聚合。

  • 原始 slides：sources/slides-ocr/2026-05-27/pdftotext-triage/11-12Domain-Driven_Design_-_Event_Storming.txt:1564-1607。该处说明事件参与者包括角色、策略、外部系统、前置事件，并在领域分析建模中强调事件、命令、聚合、读模型及读模型所属限界上下文。

  • 补充 slides：sources/slides-ocr/2026-05-27/pdftotext-triage/领域驱动设计项目实战讲解.txt:37-40, 64-67。该课件目录把“领域驱动设计”和“事件风暴”并列为 DDD 实战内容，并说明通过子领域与限界上下文划分降低业务复杂度。

**答题边界：**事件风暴不是最终架构，而是 DDD 的协作建模/发现方法；它把业务事件组织成时间线，帮助统一语言、识别参与者与策略、发现聚合和读模型，并辅助划分限界上下文。

# 企业架构：理论题拿分框架

# 脑图：企业架构从战略到实施

**记忆方法：**企业架构题不要只列 4A；按“战略 → 能力 → 4A → 治理 → 路线图”写成一条实施路径。

4A 维度 回答的问题 典型产出
业务架构 企业要做什么、能力怎样组织 能力地图、流程、业务组件
数据架构 核心业务对象与数据标准是什么 主题域、实体关系、数据标准
应用架构 哪些应用支撑哪些能力 应用组合、服务/API 映射
技术架构 底层平台和基础设施怎样承载应用 技术平台、部署与标准组件

# 企业架构 4A：从战略到数字化实施

背诵重点**：企业架构不是只列四个名词，而是说明战略目标怎样经由业务、数据、应用、技术架构**落成能力、数据资产、服务/API 与平台基础设施，并由治理和标准化持续约束。

# TOGAF

重点记 ADM 的过程与治理：以方法推进架构开发和持续治理。

# CBM

重点记业务组件：用能力与责任切分企业，支持组合和转型。

# 企业架构答题骨架：战略、能力、4A、治理

一句话定义：企业架构描述具有共同目标的组织集合体的基本组成部分、内外部关系，以及支撑设计和演进的治理原则；考试答题要把它写成战略目标到业务能力、数据资产、应用服务、技术平台的连续实施链条。

层次 怎么写 常见要点
战略 先说明企业目标、市场环境、商业模式或数字化转型诉求。 客户、产品、渠道、运营模式、风险与治理目标。
能力 把战略拆成可建设、可复用、可治理的业务能力。 能力地图、价值链、流程分解、业务组件。
4A 分别说明业务、数据、应用、技术架构怎样支撑能力。 流程模型、主题域、应用组合、平台/中间件/网络/标准。
治理 用原则、标准、评审和迁移路线保证架构持续演进。 架构愿景、迁移规划、实施治理、架构变更管理。

# TOGAF / ADM / CBM：定性与区分

**先定性：**三者不是同一层级。TOGAF 是企业架构框架，ADM 是 TOGAF 的开发流程，CBM 是业务能力/组件建模方法。

  • **TOGAF（The Open Group Architecture Framework）：企业架构框架。**管企业架构整体怎么组织、治理和演进，覆盖业务、数据、应用、技术等架构域。

  • **ADM（Architecture Development Method）：架构开发方法 / 流程。**是 TOGAF 的核心，管从架构愿景到业务架构、数据/应用架构、技术架构、迁移规划、实施治理和变更管理怎么推进。

  • **CBM（Component Business Model / Business Component Modeling）：业务组件建模。**管业务能力怎么拆成可复用、可组合的业务组件，用于识别业务边界并推导应用服务。

**好记：**TOGAF 管整体，ADM 管流程，CBM 管业务能力拆分。

记忆方法：TOGAF 记“框架和治理”，ADM 记“开发流程”，CBM 记“业务能力拆组件”。企业架构题先定性，再用“战略 → 业务建模 → 4A → 迁移治理”串起来。

# TOGAF：管整体

The Open Group Architecture Framework，是企业架构框架。记成“把企业架构工作组织起来”：范围、原则、治理、架构域和持续演进。

# ADM：管流程

Architecture Development Method，是 TOGAF 的核心流程。记成“按步骤推进”：愿景、业务、数据/应用、技术、迁移、实施治理、变更管理。

# CBM：管能力拆分

Component Business Model，是业务组件建模方法。记成“从业务能力切边界”：把能力拆成高内聚、低耦合、可复用、可组合的业务组件。

  • 4A 快速带出：业务架构看客户、产品、渠道、流程和组件；数据架构看数据资产、标准和责任；应用架构看应用蓝图、应用组件、服务共享和系统关系；技术架构看技术组件、基础设施、平台能力和技术标准。

  • 其他方法只作补充：Zachman 偏多视角描述，DoDAF 偏复杂系统/国防视图，DDD 偏从业务分析到服务边界，中台偏企业实践与商业价值结合；考试主线仍优先写 TOGAF / ADM / CBM。

# 企业架构实施路径

# 纪要补充：DDD 建模对比和设计题要点

回到总结页：纪要可能考查方式索引 已把本知识点与相关训练题互链，复习时可从题型反查本节。

**考试用法：**DDD 设计题先判断是否值得用，再从问题空间走到解空间；不要把 DDD 写成固定分层代码模板。

补充点 答题要点 常见误区
领域建模 vs 数据建模 领域建模围绕业务行为、规则和语言；数据建模围绕数据结构和持久化。 不要用表结构直接替代领域对象。
限界上下文 vs 模块 限界上下文定义模型语义边界和统一语言；模块更偏代码组织。 同名概念在不同上下文中语义可能不同。
事件风暴 领域事件用“已经发生的业务事实”命名，再从事件反推命令、聚合和上下文边界。 事件不是技术消息队列名，而是业务事实。
错误 OO 到 DDD 重构 识别贫血模型/逻辑散落 → 划上下文 → 找聚合根 → 放回业务规则 → 用事件解耦协作。 不要只把类改名为 Entity/Service。

# 纪要补充：企业架构考核边界

回到总结页：纪要可能考查方式索引 已把本知识点与相关训练题互链，复习时可从题型反查本节。

方向 需要掌握 答题边界
理论体系 4A、TOGAF/ADM、CBM 业务组件模型 偏理解和分析检查，不要求展开企业级实施细节。
实施路径 自顶向下战略业务建模；自底向上通用能力积累和中台构建 举例时回到战略、业务能力、数据对象、应用和技术支撑。
大模型支持 背景了解即可 纪要明确不作为考试内容，不进入必背内容。

  1. 自顶向下：从战略规划出发，解析价值驱动和高阶业务需求，形成战略能力。

  2. **流程建模：**用企业级建模方法把战略能力细化为流程能力、关键指标和改善机会。

  3. 应用设计：基于业务能力和数据责任设计应用组合、服务边界和集成关系，形成应用能力。

  4. **技术承载：**用平台、基础设施、中间件、网络、部署标准支撑应用服务交付。

  5. **持续治理：**通过原则、标准、评审、路线图和变更管理控制架构演进，避免系统各自为政。

复习提示：本段综合 slides/企业架构设计实战课、10Enterprise Architecture 与复习课录音。遇到企业架构题，不要只背 4A 名词；更稳的是写出战略 - 能力 - 4A - 治理 - 路线图。

# 可直接背诵答案

# 英文题面常见问法

English prompt 答题要点
When is Domain-Driven Design appropriate? 业务复杂、规则变化快、耦合变化关系复杂；简单 CRUD 不宜过度使用。
Compare strategic design and tactical design in DDD. Strategic Design 划子领域、限界上下文、上下文映射；Tactical Design 处理实体、值对象、聚合、事件、Repository。
What is a Bounded Context? 统一语言和模型保持一致的语义边界。
What is Event Storming? 从已发生的领域事件出发，识别命令、参与者、聚合和上下文边界。
What is the value of Aggregate Pattern compared with ordinary OOP? 明确一致性边界，把业务规则放回领域对象，减少贫血模型和跨边界修改。
Explain Enterprise Architecture and its main methods. 4A/5A、TOGAF/ADM、CBM；回答战略到业务、数据、应用、技术和治理实施。

# 题 1：DDD 战略设计与战术设计

DDD 适用于业务规则复杂且变化关系复杂的系统。战略设计关注宏观边界：划分子领域、识别核心域和限界上下文、形成统一语言，并用上下文映射描述不同边界之间如何协作。战术设计关注上下文内部的实现：通过实体、值对象、聚合、聚合根、领域事件、Repository 和 Factory 表达具体业务规则。前者解决“边界如何划”，后者解决“边界内部怎样保持一致”。

# 题 2：聚合模式相对普通面向对象设计的价值

聚合通过聚合根定义明确的一致性边界，外部对象只能通过聚合根访问和修改聚合内部状态。这样可以将业务不变量集中在领域对象中，防止服务层越过边界直接改数据；同时，聚合之间通过标识和领域事件协作，减少强耦合。因此聚合有助于提高封装性、一致性、可修改性和业务模型的可理解性。

# 题 3：企业架构及其数字化转型作用

企业架构描述企业核心组成部分、关系和指导其设计演进的治理原则。它通过 4A 将战略落到执行：业务架构定义能力和流程，数据架构组织业务对象和数据标准，应用架构说明应用如何支撑能力，技术架构提供平台和基础设施。企业架构在数字化转型中的作用是统一目标、标准化建设、降低复杂度并支持治理。TOGAF 强调过程与治理，CBM 强调用业务组件组织能力。

# 精选来源

  • 飞书纪要：老师关于 DDD、企业架构和考试题型/分值重点的复习提示。

  • 上传资料：《扫描文档20260526_192514.pdf》（MinerU OCR）的课程目录将 Domain-Driven Design 与 Enterprise & Business Architecture 列入复习路径。

  • 专题内容依据：老师智能纪要中关于 DDD 设计题、事件风暴、4A、TOGAF/CBM 和企业架构考法的说明。

  • 专题补充依据：原始课件 `slides/11-12Domain-Driven Design - Event Storming.pdf` 与 `slides/10Enterprise Architecture.pdf`。

  • 本地《2025软件系统设计回忆.md》《研究生往年题版.md》仅作为练题线索，不替代老师课件与纪要。

  • 新增复习录音事实源：sources/supplemental/2026-05-28/recording-review/软件体系结构复习课录音整理版.docx，用于核对事件风暴流程、七类设计决定、4A 与考试范围；整理稿不替代原始 slides。

  • 新增原始课件：slides/领域驱动设计项目实战讲解.pdf 与 slides/企业架构设计实战课-南京大学_课件版.pdf 已离线 OCR 并纳入专题补充。

  • 新增外部实践参考：美团技术团队｜DDD在大众点评交易系统演进中的应用：用于补充贫血模型、业务逻辑回归领域对象、限界上下文与微服务边界划分的实践解释。

  • 新增外部概念参考：腾讯云开发者｜DDD的宏观架构模式：用于补充 DDD 宏观架构模式、Bounded Context、Context Map 与分层等概念入口。

  • 未收入重复考题 PDF 与作业提交件；如需回溯原题，可回到本地目录查看原始文件。

(注：内容由 AI 生成，请谨慎参考）