单体改造最难的决定，往往是第一个服务拆什么。用户中心看起来通用，订单模块看起来重要，却未必适合作为试点。更稳妥的起点，是找到一个具有独立变化需求、依赖能够说明白、失败影响可以控制的业务范围。
从最近的需求单找候选模块
选取一个有代表性的迭代周期，把需求涉及的代码模块、数据表、发布人员列出来。重点寻找“内部经常一起修改、对外变化相对少”的组合。如果一个候选模块每次都要同时修改五个其他模块，先检查依赖方向，而不是立即为它建独立仓库。
试点需要同时具备收益和可控性
报表、通知或某个外部集成可以进入候选清单，但不能默认它们一定简单。报表可能直接关联大量表，通知也可能承担关键交易回执。为每个候选项记录独立发布收益、数据迁移量、故障影响和维护负责人，再比较投入。不要仅用代码行数评分。
给第一阶段设一个可结束的范围
例如只迁移某种通知的生成与发送，暂不统一所有消息渠道。写清输入契约、状态查询方式、失败处理和旧路径停止条件，保留业务校验数据。第一阶段交付应让团队学会部署、观察和恢复一个服务，而不是一次搭齐整套平台。
验收看一次真实变更
用同一种业务调整验证改造前后需要修改和发布哪些组件，再演练依赖不可用。若仍然必须全系统同步上线，应暂停扩大拆分，修正契约或边界。架构诊断的第一份成果可以就是候选模块比较表与试点验收清单。
常见问题：试点一定要选择最不重要的功能吗？
不必。价值太低的模块很难验证改造收益，依赖太复杂的模块又会掩盖方法问题。优先选择能代表真实协作方式、同时能控制影响范围的模块。
技术参考：微软：领域分析与微服务边界。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
准备推进现有 .NET 系统改造时，可以先约定一个范围明确的试点。通过单体系统渐进式改造服务梳理边界、兼容与迁移步骤，再按验证结果决定下一阶段。