领域驱动战略设计
§1摘要与结论
以限界上下文显式划定模型适用边界、以通用语言在单个上下文内统一团队与代码的表达，并通过上下文映射管理跨上下文关系的领域建模战略方法。
别名：DDD 战略设计、bounded context、限界上下文、通用语言 | 英文：DDD Strategic Design | 类型：方法 / modeling-method
§2局部关系图
§3原理 · 为什么
大型系统的领域模型无法全局一致：同一概念在不同业务语境中含义不同，强行统一会产生歧义与耦合。DDD 战略设计的核心，是在显式定义的限界上下文中让模型保持单一含义，并在该上下文内建立贯穿口头讨论与代码的通用语言。边界既是模型的适用范围，也是团队组织与物理制品（代码库、数据库 schema）的边界，与康威定律相互塑造：组织沟通结构会渗入模型边界，模型边界也会反过来约束协作方式。因此战略设计不只是技术建模，更是把领域知识、团队自治与系统边界对齐的组织性设计活动，其质量直接决定后续演化成本。忽略战略设计而直接进入战术建模，常导致模型边界与业务、团队错位。战略设计先于战术设计：若不先确定边界与语言，聚合、实体等战术模式的落地就会失去一致的语境，难以判断职责归属；因此它常与团队划分、服务拆分协同推进，而非纯由架构师在图纸上完成。
§4机制 · 如何运作
识别核心域与业务能力，划分限界上下文；每个上下文内用通用语言命名领域概念，使代码、文档与团队讨论术语一致；跨上下文通过上下文映射（partnership、customer-supplier、防腐层等）显式管理依赖与翻译，而不是共享同一模型。模型表达只有在其上下文内才有意义，跨边界必须翻译，因此上下文边界同时是一条语义边界与协作边界。上下文映射还描述团队间的权力与协作关系，使跨团队接口的依赖、方向与契约透明化，从源头减少模型污染与隐性耦合，并为拆分团队或服务提供依据。识别核心域的投入优先级，可把有限的设计精力集中在真正构成竞争力、变化最频繁的模型上。上下文映射还是组织协作的可视化工具，能暴露职责重叠、单向依赖或权力不对等等问题，为团队对话提供共同对象；映射类型的选择本身反映业务合作成熟度，可随组织演进而调整。
§5工程 · 怎么落地
以事件风暴等协作建模活动提炼通用语言与上下文边界；把上下文边界与团队边界、模块或服务边界对齐（逆康威或康威对齐）；用防腐层隔离外部或遗留模型，避免污秽模型渗入核心域；将战略设计与信息隐藏、模块化边界判据结合，使边界沿变化原因而非技术分层对齐，从而降低变更传播。应让领域专家持续参与建模，把通用语言固化到代码命名与测试用例中，并用上下文映射文档记录跨边界契约，随业务变化同步更新。对核心域投入更多设计精力，对通用/支撑域可用更简单实现；定期复看边界是否仍匹配业务，避免上下文随组织变化而僵化。对每个上下文，应明确其核心概念、对外契约与所有权，避免共享数据库或共享模型成为隐性耦合；边界并非永久不变，业务与组织变化时应重新审视上下文映射，并把跨边界调用收敛到少数明确定义的接口。每个上下文都应有清晰的 owner 与对外契约，使边界既可独立演进又可被治理。
§6权衡卡
DDD 的核心价值在战略层，是否采用应基于领域复杂度与团队能力评估，而非追随潮流。
DDD 需要领域专家深度参与与持续协作，成本高；对以 CRUD 为主、领域逻辑简单的系统，全套战略设计属过度设计，边际收益低。
反例：不做上下文划分就让多个团队共享一个大模型，导致含义漂移、改一处而动全身；或把限界上下文数量机械等同于微服务数量，无视团队协作与数据一致性成本。
第三个反例是只做建模仪式而不把通用语言落到代码与讨论中，使 DDD 退化为文档表演，徒增维护负担却无边界收益。
第四个反例是领域专家缺席，模型由技术团队闭门臆造，边界与语言均偏离真实业务；第五个反例是把战术模式当战略设计，只堆砌实体与仓储而不先厘清边界，导致模型虽精致却位置错误。
- 通用语言只在单个限界上下文内有效，误以为可全局统一会制造新的歧义。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | 领域驱动战略设计 | 架构风格选择方法 |
|---|---|---|
| 定位 / 依据层 | 领域驱动战略设计 · DDD Strategic Design | 架构风格选择方法 · Architectural Style Selection |
| 核心定义（原文） | 以限界上下文显式划定模型适用边界、以通用语言在单个上下文内统一团队与代码的表达，并通过上下文映射管理跨上下文关系的领域建模战略方法。 | 架构风格可理解为对一类系统组织方式的命名与约定：风格固定了可用构件的种类、连接方式的种类，以及二者允许如何拼装。 |
| 首条机制断言（原文） | 大型系统的领域模型无法全局一致：同一概念在不同业务语境中含义不同，强行统一会产生歧义与耦合。 | 风格之所以必然是权衡而非选优，根源在于模式把若干战术打包在一起：一旦采纳，包里每项战术带来的收益与副作用同时生效，且通常不只作用于一项质量属性。 |
| 对照关系 | 按质量属性选风格与按领域模型划边界的依据存在张力（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 反例：不做上下文划分就让多个团队共享一个大模型，导致含义漂移、改一处而动全身；或把限界上下文数量机械等同于微服务数量，无视团队协作与数据一致性成本。第三个反例是只做建模仪式而不把通用语言落到代码与讨论中，使 DDD 退化为文档表演，徒增维护负担却无边界收益。第四个反例是领域专家缺席，模型由技术团队闭门臆造，边界与语言均偏离真实业务；第五个反例是把战术模式当战略设计，只堆砌实体与仓储而不先厘清边界，导致模型虽精致却位置错误。 | 还有两类常见误区需要单独提醒：一是为追求架构上的纯洁，不分场景地把某一种风格铺满全系统； |
| 处置要点（原文） | 以事件风暴等协作建模活动提炼通用语言与上下文边界；把上下文边界与团队边界、模块或服务边界对齐（逆康威或康威对齐）；用防腐层隔离外部或遗留模型，避免污秽模型渗入核心域；将战略设计与信息隐藏、模块化边界判据结合，使边界沿变化原因而非技术分层对齐，从而降低变更传播。 | 工程上，候选边界的切法可以顺着业务能力与变更模式来提，但落锤前还要过三关：团队实际结构能否承载、运维成熟度是否跟得上、以及用敏感点与权衡点把代价显性化。 |
§8案例带
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
网申 v3 多模块解耦
一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
dsh-manager 插件深度分析
以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。
harness 源码架构解析
对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。
dsh 插件依赖增量定位
以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
§9信源与核验
核验结论：通用语言只在单个限界上下文内有意义；跨上下文须通过上下文映射显式翻译，强行全局统一会制造歧义 [BK-018]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 组合 | ← MTH-H-02 | 信息隐藏模块化分解 E-211 | 信息隐藏与限界上下文同属模块边界判据 |
| 对照 | ← MTH-G-03 | 架构风格选择方法 E-213 | 按质量属性选风格与按领域模型划边界的依据存在张力 |
| 依据推导 | → ESS-G-03 | 边界与接口隔离 E-204 | 限界上下文依边界与接口隔离原理 |
| 依据推导 | → ESS-N-01 | 康威定律 E-205 | DDD 边界与组织结构相互塑造（康威） |