3. 战略设计：限界上下文的识别与划分、上下文映射与核心域分析
战略设计是领域驱动设计（DDD）中最高层次的架构决策，它决定了软件系统的宏观结构。本章聚焦于如何通过限界上下文（Bounded Context）的识别与划分来定义模块边界，利用上下文映射（Context Map）管理跨边界协作，并通过核心域/支撑域/通用域的分类指导资源投入与架构优先级。
3.1 限界上下文的识别与划分
限界上下文是DDD中最重要的战术与战略边界。每个限界上下文对应一个独立的业务子问题域，拥有自己的统一语言（Ubiquitous Language）、领域模型和数据库模式。错误的边界划分会导致模型污染、团队冲突和系统耦合。
3.1.1 识别限界上下文的六大信号
| 信号类型 | 具体表现 | 典型示例 |
|---|---|---|
| 语言差异 | 同一术语在不同团队/模块中含义不同 | “客户”在销售团队指潜在客户，在售后团队指已签约客户 |
| 变更频率 | 部分业务逻辑变更速度显著快于其他部分 | 促销规则每周调整，而订单基础结构每月变更一次 |
| 团队结构 | 不同团队负责不同业务能力 | 支付团队、库存团队、物流团队各自独立 |
| 数据所有权 | 数据由不同部门维护，更新策略不同 | 用户画像数据由市场部维护，财务数据由财务部维护 |
| 部署独立性 | 部分功能需要独立发布和扩缩容 | 搜索服务需要高频更新，而基础用户服务低频变更 |
| 业务生命周期 | 业务实体在不同阶段有不同行为 | 订单在“待支付”“已发货”“已完成”状态下的处理逻辑差异巨大 |
3.1.2 划分原则与反模式
- 按业务能力划分：每个限界上下文封装一个完整的业务能力，如“订单管理”“库存管理”“支付处理”。
- 按业务子域划分：与问题空间（Problem Space）的子域对齐，一个子域通常对应一个限界上下文。
- 避免“大泥球”：不要将所有业务逻辑塞入一个限界上下文，即使初期看起来简单。
- 避免“微服务碎片化”：不要将每个实体或每个用例都拆成一个独立的限界上下文，导致分布式复杂性失控。
实践建议：在项目启动阶段，先识别出3-5个最明显的限界上下文，然后通过事件风暴（Event Storming）或业务场景分析逐步细化。不要追求一次性完美划分，允许在迭代中调整边界。
3.2 上下文映射（Context Map）
上下文映射是战略设计的核心工具，它描述了不同限界上下文之间的协作关系。通过上下文映射，我们可以明确每个限界上下文的职责边界、依赖方向和集成策略。
3.2.1 九种协作模式
| 模式 | 关系类型 | 适用场景 | 耦合度 |
|---|---|---|---|
| 合作关系（Partnership） | 双向依赖 | 两个团队需要紧密协作完成一个共同目标 | 高 |
| 共享内核（Shared Kernel） | 共享模型 | 两个上下文共享一小部分核心模型 | 高 |
| 客户-供应商（Customer-Supplier） | 单向依赖 | 上游（供应商）影响下游（客户） | 中 |
| 遵奉者（Conformist） | 单向依赖 | 下游完全遵循上游模型，无抗腐层 | 中 |
| 防腐层（Anticorruption Layer） | 单向依赖 | 下游需要隔离上游模型的变更影响 | 低 |
| 开放主机服务（Open Host Service） | 单向依赖 | 上游提供标准化API供多个下游使用 | 低 |
| 发布语言（Published Language） | 单向依赖 | 使用标准协议（如REST、gRPC）进行通信 | 低 |
| 分离方式（Separate Ways） | 无依赖 | 两个上下文完全独立，无任何集成 | 无 |
| 大泥球（Big Ball of Mud） | 混乱依赖 | 无明确边界，模型相互渗透（应避免） | 极高 |
3.2.2 上下文映射示例图
3.3 核心域、支撑域与通用域
在战略设计中，我们需要对业务子域进行优先级分类，以决定资源投入和架构策略。这种分类帮助团队聚焦于最具竞争力的部分，同时合理处理非核心功能。
3.3.1 三类子域定义
| 类型 | 定义 | 业务价值 | 架构策略 | 示例 |
|---|---|---|---|---|
| 核心域（Core Domain） | 企业最核心的竞争力所在，是业务差异化的来源 | 高 | 自研、投入最多资源、持续优化 | 电商的推荐算法、银行的信贷审批模型 |
| 支撑域（Supporting Subdomain） | 支持核心业务运行，但本身不构成核心竞争力 | 中 | 自研或外包，适度投入 | 订单管理、用户管理 |
| 通用域（Generic Subdomain） | 行业通用能力，无差异化价值 | 低 | 采购成熟产品、使用开源方案 | 邮件通知、身份认证、日志记录 |
3.3.2 分类决策矩阵
在识别子域类型时，可以从两个维度进行评估：业务差异化程度和内部复杂度。
- 高差异化 + 高复杂度 → 核心域：必须自研，投入最优秀的团队，持续演进。
- 高差异化 + 低复杂度 → 核心域：虽然简单，但因为是差异化来源，仍需自研。
- 低差异化 + 高复杂度 → 支撑域：考虑外包或采购，但需要一定定制。
- 低差异化 + 低复杂度 → 通用域：直接采购或使用开源方案。
常见误区：很多团队将大量资源投入到通用域（如用户认证、日志系统）的“自研轮子”上，而忽视了核心域的打磨。正确的做法是：核心域占研发资源的60%以上，支撑域占30%，通用域不超过10%。
3.3.3 核心域识别流程
- 业务愿景分析：明确企业的战略目标和核心竞争力是什么。
- 价值流映射：绘制端到端的业务价值流，识别哪些环节直接产生客户价值。
- 竞品差异分析：对比竞争对手，找出哪些能力是独有的或领先的。
- 利润贡献评估：分析各业务模块对收入和利润的贡献度。
- 专家访谈：与业务专家和产品负责人确认核心业务逻辑。
3.4 战略设计综合示例
以下是一个在线教育平台的战略设计示例，展示了限界上下文划分、上下文映射和子域分类的综合应用。
战略决策要点：
- 核心域（智能推荐、自适应学习、内容创作）全部自研，投入最优秀的算法和工程团队。
- 支撑域（订单、用户、学习进度）自研但使用成熟框架，保持适度投入。
- 通用域（通知、认证、日志）直接采购第三方服务或使用开源方案，不投入自研资源。
- 上下文映射采用防腐层模式隔离核心域与支撑域，确保核心域模型不受外部变更影响。
3.5 本章小结
- 限界上下文是战略设计的基本单元，通过语言差异、变更频率、团队结构等信号识别边界。
- 上下文映射提供了九种协作模式，帮助团队选择正确的集成策略，避免高耦合。
- 核心域/支撑域/通用域分类指导资源分配：核心域自研深耕，支撑域适度投入，通用域采购复用。
- 战略设计不是一次性的，需要随着业务发展和团队认知提升持续演进。