领域（Domain），就是你公司做的那门生意本身。

"优选门店"是做门店零售电商的，那它的领域就是"门店零售电商"。一个领域太大，没法一口吃下，所以要拆成更小的块，每一块叫一个子域（Subdomain）。

这就像一家公司要分部门：销售部、仓储部、财务部、人事部。每个部门负责一摊事，合起来才是整个公司。子域就是业务上的"部门"。

"优选门店"拆成子域： 商品子域、库存子域、订单交易子域、促销子域、会员子域、支付子域、配送子域……

到这里都还好理解。关键在下一步——这些子域不是平等的。

核心域（Core Domain）—— 你赚钱的命根子

这是你区别于竞争对手、决定生死的业务。是你公司的护城河。

对"优选门店"来说，订单交易和促销是核心域：

　　订单交易是营收的直接来源，下单转化率、履约体验直接决定生意。

　　促销是零售电商的核心武器——满减、优惠券、限时折扣玩得好不好，直接决定 GMV。隔壁竞品的促销规则更灵活，用户就跑了。

核心域要投入最强的团队、用最精细的 DDD 建模。 这套教程后面的聚合、领域事件、CQRS，主要就是给核心域用的。

支撑域（Supporting Subdomain）—— 必须有，但不构成竞争力

业务离不开它，但它做得再好也不会让你"赢"，只是"不输"。

对"优选门店"来说，商品管理、库存、配送是支撑域：

　　商品要有、库存要准、货要能发出去，缺一不可。

　　但"商品管理系统做得特别牛"不会成为你打败对手的理由。它只要"够用、稳定"就行。

支撑域可以用相对简单的方式实现，甚至可以外包或买成品，没必要上最复杂的建模。

通用域（Generic Subdomain）—— 大家都一样，能买就买

任何公司都需要、且做法高度标准化的业务。

对"优选门店"来说，支付、消息通知、对账是通用域：

　　支付？直接接微信支付/支付宝/银联。

　　 短信通知？买第三方服务。

　　 自己从零造一个支付系统，纯属浪费——这不是你的竞争力所在。

通用域优先用现成方案（第三方服务、开源组件、SaaS），别自己造轮子。

一张图看懂"优选门店"的子域划分

传统做法的弊端

传统项目里，所有模块一视同仁：商品管理和订单交易投入一样的人力，支付系统也想自己从头造一套"更好的"。结果是：

　　把宝贵的资深工程师耗在"商品类目管理"这种支撑域上，核心的促销引擎却草草了事。

　　 自研支付、自研短信网关，造了一堆没有竞争力的轮子，还埋了一堆坑。

　　整个系统平均用力，核心竞争力没建起来，次要的地方又过度投入。

这样分的好处

1.  资源聚焦：最强的人 + 最精细的建模，集中砸在核心域（订单、促销），把护城河挖深。
2. 降本提速：支撑域够用即可、通用域直接买，省下的时间投到核心域。
3. 决策有依据：要不要自研、要不要外包、用不用复杂架构，看它是哪类子域就有答案了。

容易踩的坑

• • 核心域不是一成不变的。早期"优选门店"的核心可能是"商品丰富度"，成熟期变成"促销和履约效率"。要定期重新评估。
• • 别把"技术难"当成"核心域"。搜索引擎技术上很难，但如果它不是你区别于对手的关键，它就只是支撑域，该用现成的 ES 就用，别自研。核心域看的是业务价值，不是技术难度。
• • 核心域要尽量小而聚焦。什么都说是核心，等于没有核心。

---

划分完子域，下一步是 DDD 里最重要也最容易被低估的概念——限界上下文。子域是业务视角的划分，限界上下文则是落到软件设计上的边界。