fix img

专栏/领域驱动设计实践（完）/016 识别限界上下文（下）.md.html

@@ -583,7 +583,7 @@ function hide_canvas() {
 <p>自治原则的唯一例外是遗留系统，因为领域驱动设计建议的通常做法是将整个遗留系统视为一个限界上下文。那么，什么是遗留系统？根据维基百科的定义，它是一种旧的方法、旧的技术、旧的计算机系统或应用程序，这个定义并不能解释遗留系统的真相。我认为，系统之所以成为遗留系统，关键在于<strong>知识的缺乏</strong>。文档不够全面真实，掌握系统知识的团队成员泰半离开，系统的代码可能是一个大泥团。因此，我对遗留系统的定义是“<strong>一个还在运行和使用，但已步入软件生命衰老期的缺乏足够知识的软件系统</strong>”。</p>
 <p>倘若运用领域驱动设计的系统要与这样一个遗留系统打交道，应该怎么办？窃以为，粗暴地将整个遗留系统包裹在一个限界上下文中，未免太理想化和简单化了。要点还是<strong>自治</strong>，这时候我们应该站在遗留系统的调用者来观察它，考虑如何与遗留系统集成，然后逐步对遗留系统进行抽取与迁移，形成自治的限界上下文。</p>
 <p>在这个过程中，我们可以借鉴技术栈迁移中常常运用的“抽象分支（Branch By Abstraction）”手法。该手法会站在消费者（Consumer）一方观察遗留系统，找到需要替换的单元（组件）；然后对该组件进行抽象，从而将消费者与遗留系统中的实现解耦。最后，提供一个完全新的组件实现，在保留抽象层接口不变的情况下替换掉遗留系统的旧组件，达到技术栈迁移的目的：</p>
-<p><img src="assets/c9803d20-a361-11e8-a938-3b329a942b7b" alt="enter image description here" /></p>
+<p><img src="assets/c9803d20-a361-11e8-a938-3b329a942b7b" alt="png" /></p>
 <p>如上图所示的抽象层，本质就是后面我们要提到的“防腐层（Anticorruption Layer）”，通过引入这么一个间接层来隔离与遗留系统之间的耦合。这个防腐层往往是作为下游限界上下文的一部分存在。若有必要，也可以单独为其创建一个独立的限界上下文。</p>
 <h3>设计驱动力</h3>
 <p>结合业务边界、工作边界和应用边界，形成一种层层推进的设计驱动力，可以让我们对限界上下文的设计变得更加准确，边界的控制变得更加合理，毕竟，限界上下文的识别对于整个系统的架构至关重要。在领域驱动的战略设计阶段，如果我们对识别出来的限界上下文的准确性还心存疑虑，那么比较实际的做法是保持限界上下文一定的粗粒度。倘若觉得功能的边界不好把握分寸，可以考虑将这些模棱两可的功能放在同一个限界上下文中。待到该限界上下文变得越来越庞大，以至于一个 2PTs 团队无法完成交付目标；又或者该限界上下文的功能各有不同的质量属性要求；要么就是因为重用或变化，使得我们能够更清楚地看到分解的必要性；此时我们再对该限界上下文进行分解，就会更加有把握。这是设计的实证主义态度。</p>