用途：将领域驱动设计（DDD）作为对齐系统架构与业务现实的思考工具，用于判断系统边界应如何划分、模型应如何组织。核心观点是：多数系统失败并非技术选型问题，而是结构不匹配所解决的问题。
主要能力与概念：
- 通用语言：每个限界上下文内，开发者、领域专家、产品经理与代码共用同一套词汇，代码即语言的唯一事实来源；语言边界可揭示系统边界。
- 限界上下文：同一术语在上下文内只有一个含义，跨上下文可含义不同；它可以是微服务、模块、命名空间或独立 schema，关键词是模型隔离而非部署拓扑。
- 上下文映射：描述上下文间关系并选择集成模式，包括共享内核、客户-供应商、遵奉者、防腐层、开放主机服务、发布语言。选择依据是对上游团队的信任与影响力，以及双方模型的差异程度。
- 聚合：作为数据变更一致性边界的对象簇，只有聚合根可被外部直接引用；原则是“一次事务一个聚合”，聚合应尽量小，跨聚合通过身份引用，最终一致。
- 领域事件：以过去时命名、承载必要数据、不可变、需版本化的业务事实，用于跨聚合一致性、跨上下文集成与审计历史。
- 事件风暴：协作式发现领域事件、命令、聚合与上下文边界的研讨会技术。
使用方式：在审视一个难以理解的系统时，用上述概念识别语言摩擦、数据模型用途混杂、“if type == A else if type == B”式分支等信号，进而划分上下文边界、选择集成模式、确定聚合与事件。
适用场景：复杂业务规则领域（如保险理赔、订单履约、计费）的架构设计与边界划分。
限制：若领域本质为 CRUD，聚合可能只增加复杂度而无价值；战术模式具有情境性，战略模式价值更普遍；不得把多个上下文强行合并为“规范模型”；事件风暴与上下文映射的具体操作细节、安装或代码用法，资料中暂未提供。