fix img

专栏/领域驱动设计实践（完）/048 领域实现模型.md.html

@@ -534,7 +534,7 @@ function hide_canvas() {
 <li>第二个阶段是测试驱动开发：依照事先拆分好的任务，进一步结合业务场景将任务划分为多个可以验证的测试用例，然后开始编写测试，并按照红—绿—重构的节奏开始编码实现。</li>
 </ul>
 <p>分解的任务是有层次的，大致可以划分为<strong>业务价值、业务功能与业务实现</strong>三个层次。这三个层次还可以进一步递归分解，这取决于业务场景的粒度。在选择测试要驱动的任务时，可以采用自外向内或自内向外这两种不同的实现方向。在建立领域设计模型时，我们往往会采用自外向内的方向，这其实就是前面讲解的服务模型驱动设计的设计方向，符合“意图导向编程”的思想。而在选择测试用例时，则应该反其道而行之，从最小粒度的原子任务开始，这样在一定程度上能减少不必要的 Mock 协作，也能够减少最外层服务因为分支覆盖率的原因带来的测试用例组合爆炸：</p>
-<p><img src="assets/bcc13da0-95b9-11e9-a862-93dd78d50384" alt="79098254.png" /></p>
+<p><img src="assets/bcc13da0-95b9-11e9-a862-93dd78d50384" alt="png" /></p>
 <p>测试驱动开发严格遵循 Kent Beck 提出的<strong>简单设计</strong>原则，内容为：</p>
 <ul>
 <li>通过所有测试（Passes its tests）</li>
@@ -548,7 +548,7 @@ function hide_canvas() {
 <p><strong>“尽可能清晰表达”原则</strong>要求代码要简洁而清晰地传递领域知识，在领域驱动设计的语境下，就是要遵循统一语言，提高代码的可读性，满足业务人员与开发人员的交流目的。针对核心领域，甚至可以考虑引入领域特定语言（Domain Specific Language，DSL）来表现领域逻辑。</p>
 <p>在满足这三个原则的基础上，<strong>“更少代码元素”原则</strong>告诫我们遏制过度设计的贪心，做到设计的恰如其分，即在满足客户需求的基础上，只要代码已经做到了最少重复与清晰表达，就不要再进一步拆分或提取类、方法和变量。</p>
 <p>这四个原则是依次递进的，功能正确、减少重复、代码可读是简单设计的根本要求。一旦满足这些要求，就不能创建更多的代码元素去迎合未来可能并不存在的变化，避免过度设计。当简单设计原则与测试驱动开发结合起来之后，测试保证了功能的正确性，重构则保证了代码的质量。由于有大量的测试保护，即使未来发生了变化，也能让开发人员在调整代码结构应对变化时充满信心。测试、实现与重构共同构成了测试驱动开发的核心：</p>
-<p><img src="assets/1ff3ae30-95ba-11e9-b2ae-6342cbacc966" alt="32822541.png" /></p>
+<p><img src="assets/1ff3ae30-95ba-11e9-b2ae-6342cbacc966" alt="png" /></p>
 <blockquote>
 <p>图片来源于网络</p>
 </blockquote>
@@ -562,7 +562,7 @@ function hide_canvas() {
 <li>需要你对环境做特定的准备（如编辑配置文件）才能运行的</li>
 </ul>
 <p>这些职责恰好属于业务逻辑需要调用的所谓“南向网关”的部分，被放在整洁架构的最外侧一环，如下图所示的 DB、Devices 与 External Interfaces：</p>
-<p><img src="assets/cc672c00-95ba-11e9-a862-93dd78d50384" alt="35360091.png" /></p>
+<p><img src="assets/cc672c00-95ba-11e9-a862-93dd78d50384" alt="png" /></p>
 <blockquote>
 <p>图片来源于网络</p>
 </blockquote>
@@ -605,7 +605,7 @@ public void should_transfer_from_src_account_to_dest_account_given_correct_trans
 <p>整体而言，在领域模型驱动设计的语境下，领域分析模型从业务系统中抽象出核心的领域概念，与领域专家一起获得领域见解，并提炼出有价值的领域知识，从而建立一个有利于与领域专家沟通的抽象模型。领域分析模型与任何软件开发技术都没有关系，只取决于团队对领域知识的理解。</p>
 <p>领域设计模型则是在领域分析模型基础上的技术演进，例如对领域分析模型中的领域对象进行职责分配，建立抽象接口完成模块以及对象之间的解耦，对代表领域概念的类进行更合理的封装，隐藏不必要的细节，并对领域分析模型中的领域对象运用 Eric Evans 提出的设计要素与模式。</p>
 <p>领域实现模型提供遵循领域设计模型的编程实现，这时需要考虑具体的实现机制，但同时又必须保持业务复杂度与技术复杂度的分离，避免出现复杂度的叠加效应。当然，实现模型总是由编程语言来表示，不同语言有不同的惯用法、不同的语法糖，即使在相同语言下，选择不同的框架，由于框架的设计原则和思路亦有所不同，导致实现模型会有所区别。整个领域模型驱动设计的过程如下图所示：</p>
-<p><img src="assets/8adf3e20-95bb-11e9-9279-23d239944d33" alt="50470213.png" /></p>
+<p><img src="assets/8adf3e20-95bb-11e9-9279-23d239944d33" alt="png" /></p>
 <p>在领域模型驱动设计过程中，是领域分析模型、领域设计模型与领域实现模型共同构成了领域模型，因此这里列出的三个模型并不是独立无关的，与之对应的建模活动也不是独立无关的。这三个模型是统一的整体，只是在不同的阶段需要有不同的分析建模方法，又因为交流的对象不同，需要有不同的模型呈现形式。因此，要掌握领域驱动设计，在战术设计层面就必须要理解什么才是真正的领域模型。</p>
 </div>
                     </div>