60 遗留系统改造（下）：增量改造 vs 重构，如何选择？（案例分析）
你好，欢迎来到第 60 讲。
在上一讲，我们学习了改造遗留系统的 4 个宏观战略步骤，其核心是采用“绞杀者模式”进行增量替换。
然而，在具体的“增量替换”这一步中，我们又会面临一个关键的战术决策：对于一个我们想要替换的旧功能，我们应该采用什么样的姿态来构建它的新版本？
业界主要有两种不同的声音：
- 增量改造派：我们应该严格遵守“小步快跑”的原则。对于旧功能，只做最小化的、最必要的改造，尽快地用新服务替换掉它，然后再在新的服务上，进行持续的优化和重构。
- 大爆炸重构派：既然已经决定要替换了，就应该“一步到位”。我们应该花足够的时间，对这个功能的业务逻辑进行一次彻底的重新梳理和领域建模，用最完美的 DDD 设计，来构建一个全新的、理想的版本。
这两种选择，代表了在“速度”和“质量”之间的不同权衡。它们没有绝对的对错，但在不同的场景下，会产生截然不同的效果。
本讲，我们将深入这个战术决策的细节，通过两个真实的案例分析，来探讨“增量改造”和“大爆炸重构”各自的优劣和适用场景。这将帮助你在面对具体的改造任务时，做出更明智的、风险收益比最高的选择。
不用Spring的Autowire且能看出依赖关系的写法)