为什么先把大领域拆成中台子域再建模：事件风暴范围要可控

中台业务建模的第一步，是先按核心业务流程节点或功能属性集合，把整个业务领域细分为多个中台（再归到核心中台或通用中台），而不是直接在一个巨大的领域上开展领域建模。书中给出的理由很直接：如果业务领域太大，不便于开展事件风暴——事件风暴是一项需要领域专家和项目团队通过头脑风暴逐条梳理命令、领域事件、领域对象及其关系的活动，参与讨论的业务范围一旦过大，讨论会失去焦点、遗漏细节的风险也会大增，实际操作上根本无法在一次或几次工作坊里覆盖完整。所以更可行的做法是先按业务职能和功能聚合边界，把大领域拆成大小合适的中台（子域），再分别对每个中台单独构建领域模型。这条理由和[[DDD子域递归细分拆到适合团队建模的粒度为止]]背后是同一个逻辑：无论是决定子域切多细，还是决定该在多大范围内做一次事件风暴，判断标准都不是纯理论上的”领域该怎么分才最优雅”，而是”这个范围内的复杂度，团队和方法本身是否真的能有效处理”。