fix img

专栏/领域驱动设计实践（完）/023 分层架构的演化.md.html

@@ -421,7 +421,7 @@ function hide_canvas() {
 <p>分层架构是一种架构模式，但终归它的目的是为了改进软件的架构质量，我们在运用分层架构时，必须要遵守架构设计的最高原则，即建立一个高内聚、松耦合的软件系统架构。于是，许多设计大师们纷纷提出了自己的洞见。</p>
 <h3>整洁架构</h3>
 <p>在架构设计时，我们应设计出干净的应用层和领域层，保持它们对业务逻辑的专注，而不掺杂任何具体的技术实现，从而完成领域与技术之间的完全隔离，这一思想被 Robert Martin 称之为<strong>整洁架构（Clean Architecture）</strong>。下图展现了 Robert Martin 的这一设计思想：</p>
-<p><img src="assets/99c97c50-b1ac-11e8-867a-f71becc2a480" alt="enter image description here" /></p>
+<p><img src="assets/99c97c50-b1ac-11e8-867a-f71becc2a480" alt="png" /></p>
 <p>该架构思想提出的模型并非传统的分层架构，而是类似于一个内核模式的内外层架构，由内及外分为四层，包含的内容分别为：</p>
 <ul>
 <li>企业业务规则（Enterprise Business Rules）</li>
@@ -460,7 +460,7 @@ function hide_canvas() {
 </ul>
 <h3>微服务架构</h3>
 <p>Toby Clemson 在《<a href="https://martinfowler.com/articles/microservice-testing/">微服务架构的测试策略</a>》一文中深入探讨了如何对微服务架构制定测试策略。要明确如何对这样的系统进行测试，就需要明确该系统架构的组成部分以及各组成部分承担的职责，同时还需要了解各组成部分之间的协作关系。为此，Toby 在这篇文章中给出了一个典型的微服务架构，如下图所示：</p>
-<p><img src="assets/b8af87d0-b1ad-11e8-867a-f71becc2a480" alt="enter image description here" /></p>
+<p><img src="assets/b8af87d0-b1ad-11e8-867a-f71becc2a480" alt="png" /></p>
 <p>该架构图并未严格按照分层架构模式来约定各个组件的位置与职责，这是完全合理的设计！当我们需要将一个分层架构进行落地实践时，在任何一门语言中我们都找不到所谓 layer 的明确语法。在 Java 语言中，我们可以通过 package 与 module 去划分包与模块，在 Ruby 语言中我们也可以限定 module 的范畴，但我们并不能通过某种语法甚至语法糖去规定 layer 的边界。所以在编码实现中，layer 其实是一个松散且不够严谨的逻辑概念，即使我们规定了层的名称以及各层的职责，但各种“犯规行为”依然屡见不鲜。与其如此，不如将各个组件在逻辑架构中的位置与职责明确定义出来。对于系统的概念模型与设计模型，我们要明确分层架构的本质与设计原则；对于代码模型，分层架构则主要负责设计指导，并酌情弱化层在代码模型中的意义，强化对包与模块的划分。</p>
 <p>上图的逻辑边界代表了一个微服务，这是基于微服务的设计原则——“<strong>每个微服务的数据单独存储</strong>”，因此需要将物理边界（图中定义为网络边界）外的数据库放在微服务的内部。</p>
 <p>整幅图的架构其实蕴含了两个方向：<strong>自顶向下</strong>和<strong>由内至外</strong>。</p>