微前端粒度选择：看业务流程完整性，而非机械按领域模型拆分

[[业务单元的三种组合方式单一组合通用]]已经说明一个微前端可以对接一个或多个微服务，但书中进一步给出了具体怎么选的判断依据：不是看”这个中台有几个领域模型”就机械地拆出几个微前端，而是要先问两个问题。第一，这几个领域模型是否面向完全不同的业务场景？如果是（比如支付中心的收款和付款，一个面向收款场景一个面向付款场景，两者用户旅程完全不搭界），即使它们同属一个中台，也应该分别设计各自的微前端，组合成不同的业务单元，而不是强行捏在一起。第二，如果这几个领域模型其实是同一条业务流程里前后相继的环节，是否为了保证这条流程在前端呈现的完整性和用户体验，值得把它们合并进同一个微前端（此时该微前端对接多个微服务，构成组合业务单元）？这一步判断服从一条更高优先级的原则：”当前端架构设计和用户体验两者发生冲突时，应该毫不犹豫地选择用户体验”——也就是说，”领域模型边界清晰”本身不是目的，只是手段，如果机械按领域模型一刀切拆分微前端会牺牲用户在业务流程中的连贯体验，那么应该优先保全体验完整性，而不是死守边界纯粹性。