ddd-subdomain-classification

一句话总结

将每个子领域归类为核心、支撑或通用，以便把建模精力投入到真正能体现业务差异的部分。

何时使用此技能

• 制定路线图范围，并确定哪些领域值得深入设计。
• 为一块功能选择自建还是采购。
• 在各团队之间分配资深工程师。
• 为投入过多基础设施工作的项目砍掉部分范围。

何时不使用此技能

• 子领域内部的建模问题 → 使用战术模式技能。
• 划定上下文边界 → ddd-bounded-context。

核心内容

这三个类别依据它们在业务中扮演的角色命名：

核心领域。 让公司区别于竞争对手的业务部分，也是客户选择这款产品而非其他产品的原因。这里值得投入资深人员进行建模。不要外包，不要套用模板，也不要“直接用个库”。

支撑子领域。 必不可少，有一定定制需求，但并非公司的竞争优势所在。可以构建，但要适度——目标是“满足我们的需求”，而不是“做到业内最佳”。

通用子领域。 普通商品化功能。身份验证、基础计费、地址验证、文件存储、关键词搜索。购买现成方案（Stripe、Auth0、Algolia）、使用库，或采用现成框架。自建通用子领域，是软件开发中代价最高的错误之一。

判断标准。“如果这个子领域明天消失，客户会注意到并在意吗？竞争对手能把它做得比我们更好吗？”两个答案都是“是”→核心。两个答案都是“否”→通用。介于两者之间→支撑。

决策启发

• 问：“我们能否使用 Stripe / Auth0 / SaaS 服务 / 框架默认功能？”——能，说明它是通用子领域；构建集成即可，无须重造功能本身。
• 问：“如果客户选择我们而非竞争对手，他们会提到哪项功能？”——那就是核心；据此配置人员。
• 每次重要的路线图评审时重新分类。子领域会随时间迁移（原本通用的功能可能变成核心，反之亦然）。

反模式

• 把每个子领域都当作核心——结果没有任何领域能获得资深人员的关注，真正的核心反而投入不足。
• 对通用子领域过度设计（从头重建身份验证、构建自定义邮件系统、编写新的搜索引擎）。
• 因为实际核心“感觉很无聊”，或团队更愿意处理光鲜的通用基础设施，而对核心投入不足。
• 将核心外包给供应商——公司会失去使其脱颖而出的东西。

另请参阅

• ddd-bounded-context — 被分类的单元。
• ddd-design — 设计投入应根据此分类分配。

参考资料

• Evans，《Domain-Driven Design》（2003），第 15 章（提炼）。