DDD子域递归细分：拆到适合团队建模的粒度为止

DDD处理业务问题的方式是按一定规则对业务领域做细分：先把领域分解成子域，子域还可以继续细分成子子域，这个递归细分过程没有一个统一的、放之四海而皆准的停止条件——书中给出的判断标准是”一直细分到你认为这个子域的大小，正好适合你的团队开展领域建模工作为止”。子域细分完成后，还要按重要性和功能属性把它们归为核心子域、支撑子域、通用子域三类，才能进而确定资源投入策略和中台的领域边界。这里揭示了一个容易被忽视的设计原则：领域细分的”合适粒度”不是一个纯粹客观、脱离组织现实的技术判断，而是要把”团队实际能够消化和管理这个子域的建模复杂度”作为停止细分的判据之一——子域切得太大，团队没法在合理时间内把领域模型想清楚；切得太细碎，又会制造出大量需要协调管理的边界，反而增加整体复杂度，细分粒度本质上是在”领域复杂度”和”团队认知与协作负荷”之间寻找的一个平衡点。