面向IaaS企业的DDD核心子域划分困惑及合理分解方法问询

核心子域的判断逻辑 #

DDD里的核心子域不是看营收占比，而是企业的差异化竞争护城河——也就是客户选择你而不选竞品的核心原因：

• 如果这家企业靠自研的弹性云资源调度引擎打市场，那cloud是核心子域；
• 如果主打托管服务的一站式运维（比如给中小客户做全托管的服务器运维），那hosting是核心；
• 如果自研的分布式数据库有独特的性能/成本优势，那database才是核心。

核心子域要集中最优质的开发资源，做深度定制化和差异化，其他高价值服务哪怕营收高，也只是支撑子域。

子域拆分具体建议 #

• 核心子域：选定上述的核心服务，聚焦其最具竞争力的模块（比如cloud的资源调度、计费模型；database的分布式一致性算法），这部分是团队攻坚的重点。
• 支撑子域：剩下的hosting、database（如果不是核心）归为支撑子域，每个子域单独拆分：
  • hosting子域专注托管服务的运维自动化、环境部署、监控告警；
  • database子域专注数据库的备份容灾、性能优化、实例管理。
    每个支撑子域配独立的小团队，不用跨多个服务，避免负担过重。
• 通用子域：DDoS防护（如果是标准化方案或第三方集成）、统一用户管理、支付流程这类通用功能，归为通用子域，优先用成熟组件或外包，减少自研成本。

避免团队负担过重的关键 #

不要把所有服务硬塞进一个infrastructure subdomain，而是按业务复杂度+竞争优先级拆分：

• 核心子域团队只负责差异化核心逻辑；
• 支撑子域团队专注各自服务的业务闭环，和核心子域通过清晰的接口协作；
• 通用子域尽量复用现有方案，节省开发资源。

内容的提问来源于stack exchange，提问作者Patrick