microwind 领域划分 (Domain Partitioning)
概述
领域划分是将复杂业务分解为可管理的子域，并识别哪些是核心竞争力、哪些是支撑能力、哪些是通用能力。
什么是"领域"
领域 (Domain)：一个组织所要做的整个事情，以及这个事情下所包含的一切内容。
关键理解：
领域是一个范围概念，是面向业务的：
❌ 不是面向技术的（不是"Java 领域"、"前端领域"）
❌ 不是面向数据库持久化的（不是"订单表领域"）
✅ 是一个组织所做的整个业务（人员、规则、流程、知识）
当你为该组织开发软件的时候，你面对的就是这个组织的领域。
示例：
| 组织 | 领域 |
|---|---|
| RabbitTech 的 RabbitAdvisors | 知识付费领域 / 付费咨询领域 |
| 蚂蚁金服 | 金融科技领域 |
| 高德地图 | 地图与位置服务领域 |
| 亚马逊 | 电商零售领域 |
| Salesforce | CRM 领域 |
为什么要划分子域：分而治之
领域本身很大很复杂，无法一次建模。DDD 采用分而治之的思想：
复杂领域
│
│ 拆分
▼
子域 A + 子域 B + 子域 C + ...
│ │ │
│ │ │ 继续拆分（如有必要）
▼ ▼ ▼
聚合 聚合 聚合
│ │ │
▼ ▼ ▼
代码实现
分治的好处：
- 每个子域可以独立建模、独立演进
- 不同子域可以投入不同量级的资源
- 子域之间可以由不同团队并行推进
- 局部复杂度可控，整体复杂度被拆解
子域（Subdomain）
子域：在一个大的领域中，可以进一步划分出来的独立的业务子领域，它们有着自己的业务概念、规则和流程等。
示例（RabbitAdvisors）：
知识付费领域 (Domain)
│
├── 订阅域 (Subdomain) — 读者订阅专栏、管理订阅状态
├── 订单域 (Subdomain) — 订单创建、支付、退款
├── 专栏域 (Subdomain) — 专栏内容管理
├── 金融域 (Subdomain) — 对接支付网关、分账
├── 签约域 (Subdomain) — 作者合同管理
├── 佣金域 (Subdomain) — 佣金计算与支付
└── 用户域 (Subdomain) — 读者、作者、编辑
子域分类
┌─────────────────────────────────────────┐
│ 业务领域 │
├──────────┬──────────┬───────────────────┤
│ 核心域 │ 支撑域 │ 通用域 │
│ Core │ Supporting│ Generic │
│ │ │ │
│ 竞争优势 │ 必要但非 │ 所有公司都需要 │
│ 最高投入 │ 差异化的 │ 可用现成方案 │
│ 最优人才 │ 中等投入 │ 最低投入 │
└──────────┴──────────┴───────────────────┘
电商平台划分示例
| 子域 | 类型 | 投入策略 |
|---|---|---|
| 个性化推荐引擎 | 核心域 | 自研，顶级团队 |
| 定价与促销策略 | 核心域 | 自研，持续优化 |
| 订单管理 | 支撑域 | 自研但不过度投入 |
| 库存管理 | 支撑域 | 自研或定制化方案 |
| 用户认证 | 通用域 | 使用现成方案（Auth0等） |
| 邮件通知 | 通用域 | 使用SaaS服务 |
| 支付处理 | 通用域 | 集成第三方（Stripe等） |
识别方法
对每个子域问自己：
1. 这是我们的竞争优势吗？
是 → 核心域
2. 没有它业务能运转吗？
不能，但不是差异化因素 → 支撑域
3. 所有同行业公司都需要它吗？
是 → 通用域
与其他DDD概念的关系
| 概念 | 关系 |
|---|---|
| 限界上下文 | 子域通常对应一个或多个限界上下文 |
| 核心域、支撑域、通用域 | 子域的分类方式 |
| 微服务中的DDD | 子域划分指导微服务拆分 |
总结
核心：识别哪些是竞争优势（核心域），集中资源投入。
实践：核心域自研 + 最优人才，通用域用现成方案，支撑域适度投入。