限界上下文只是微服务拆分的重要依据，而非唯一标准

用户中台的领域建模按四步完成：提取实体（从场景分析产生的命令和事件中找出用户、账户、认证票据、系统、菜单、岗位、用户日志等实体）、构建聚合（找出用户、系统等聚合根，把关联实体值对象组合成系统功能、岗位、用户信息等六个聚合）、划定限界上下文（按业务语义把聚合归类成用户信息、认证、权限三个限界上下文）、建立领域模型上下文服务地图（理清限界上下文间的服务依赖，截断可能的循环依赖）。原则上一个限界上下文可以直接设计成一个微服务，但书中明确提醒：限界上下文只是微服务拆分的一个非常重要的依据，不能作为唯一标准，因为领域建模时只考虑了业务因素，没有考虑技术、团队沟通、运行环境等非业务因素。书中给出真实案例：用户信息聚合和用户日志聚合虽然在业务语义上同属一个限界上下文，但如果用户日志数据量巨大到需要用大数据技术单独处理，而用户信息聚合仍用常规技术栈，两者就出现了技术异构，这种情况下即使业务边界上归为一类，落地时也应该拆成两个采用不同技术栈的微服务。