fix img

专栏/DDD 微服务落地实战/00 开篇词 让我们把 DDD 的思想真正落地.md.html

@@ -165,10 +165,10 @@ function hide_canvas() {
 <h4>第 3 幕：谁来拯救微服务</h4>
 <p>2015 年，互联网技术的飞速发展带给了我们无限发展的空间。越来越多的行业在思考：如何转型互联网？如何开展互联网业务？这时，一个互联网转型的利器——微服务，它恰恰能够帮助很多行业很好地应对互联网业务。于是乎，我们加入了微服务转型的滚滚洪流之中。</p>
 <p>但是，<strong>微服务也不是银弹，它也有很多的“坑”</strong>。</p>
-<p><img src="assets/Ciqc1F-yNB-ADKSxAAUaE9dRRdU695.png" alt="ddd.png" /></p>
+<p><img src="assets/Ciqc1F-yNB-ADKSxAAUaE9dRRdU695.png" alt="png" /></p>
 <p>当按照模块拆分微服务以后才发现，每次变更都需要修改多个微服务，不但多个团队都要变更，还要同时打包、同时升级，不仅没有降低维护成本，还使得系统的发布比过去更麻烦，真不如不用微服务。<strong>是微服务不好吗</strong>？我又陷入了沉思。</p>
 <p>这时我才注意到 <strong>Martin Flower 在定义微服务时提到的“小而专”，很多人理解了“小”却忽略了“专”，就会带来微服务系统难于维护的糟糕境地</strong>。这里的“专”，就是要“小团队独立维护”，也就是尽量让每次的需求变更交给某个小团队独立完成，让需求变更落到某个微服务上进行变更，唯有这样才能发挥微服务的优势。</p>
-<p><img src="assets/Ciqc1F-yIsyAONSrAAB8S9PQpFM405.png" alt="1.png" /></p>
+<p><img src="assets/Ciqc1F-yIsyAONSrAAB8S9PQpFM405.png" alt="png" /></p>
 <p>通过这样的一番解析，才发现微服务的设计真的不仅仅是一个技术架构更迭的事情，而是对原有的设计提出了更高的要求，即“微服务内高内聚，微服务间低耦合”。<strong>如何才能更好地做到这一点呢？答案还是 DDD。</strong></p>
 <p>我们转型微服务的重要根源之一就是系统的复杂性，即系统规模越来越大，维护越来越困难，才需要拆分微服务。然而，拆分成微服务以后，并不意味着每个微服务都是各自独立地运行，而是彼此协作地组织在一起。这就好像一个团队，规模越大越需要一些方法来组织，而 DDD 恰恰就是那个帮助我们组织微服务的实践方法。</p>
 <h4>第 4 幕：DDD，想说爱你不容易</h4>
@@ -176,7 +176,7 @@ function hide_canvas() {
 <p>有了这个技术中台的支持，开发团队就可以把更多的精力放到对用户业务的理解，对业务痛点的理解，快速开发用户满意的功能并快速交付上。这样，不仅编写代码减少了，技术门槛降低了，还使得日后的变更更加容易，技术更迭也更加方便。因此，我又开始苦苦求索。</p>
 <p>很快，Bob 大叔的整洁架构（Clean Architecture）给了我全新的思路。整洁架构最核心的是业务（图中的黄色与红色部分），即我们通过领域模型分析，最后形成的那些 Service、Entity 与 Value Object。</p>
 <p>然而，整洁架构最关键的设计思想是通过一系列的适配器（图中的绿色部分），将业务代码与技术框架解耦。通过这样的解耦，上层业务开发人员更专注地去开发他们的业务代码，技术门槛得到降低；底层平台架构师则更低成本地进行架构演化，不断地跟上市场与技术的更迭。唯有这样，才能跟上日益激烈的市场竞争。</p>
-<p><img src="assets/Ciqc1F-yItuAPhLzAAEmftrVMI8732.png" alt="2.png" /></p>
+<p><img src="assets/Ciqc1F-yItuAPhLzAAEmftrVMI8732.png" alt="png" /></p>
 <p>图片来自 Robert C. Martin 的《架构整洁之道》</p>
 <p>不仅如此，我在实践摸索过程中，还创新性地提出了单 Controller、通用仓库、通用工厂，以及完美支持 DDD + 微服务的技术中台架构设计。通过这些设计，开发团队能够更好地将 DDD 落地到项目开发中，真正地打造出一支支理解业务、高质量开发与快速交付的团队。</p>
 <h3>这门课能让你学到什么？</h3>