fix img

专栏/领域驱动设计实践（完）/056 统一语言与领域分析模型.md.html

@@ -446,7 +446,7 @@ function hide_canvas() {
 <p><strong>注</strong>：这里绘制的用例图并未采用 UML 的标准用例图形式，各种颜色的便利贴分别代表了参与者、主用例和子用例。我希望通过这种形式再次说明利用可视化工具进行领域建模的重要性。</p>
 <p>用例描述要求言简意赅，但并不意味着我们不追求用例描述的精确。图中的付现汇和付票据主用例都包含了“提交银行”子用例。这个用例的描述语焉不详，甚至会被认为是同一个重用的子用例。经过不断交流，才发现这里遗漏了重要的领域概念。付现汇主用例中的“提交银行”子用例其实是“提交收款指令”，而付票据主用例的“提交银行”子用例则是“提交电票指令”。因此，类似用例这样的领域场景分析方法，是领域分析模型的重要源头，若源头被“污染”了，就会影响到领域分析模型的质量。对领域场景的分析，必须字斟句酌，比作家对待写作还要精确与严谨。</p>
 <p>无论是用例，还是用例图，只要遵照了这样的分析要求，我们就可以利用“名词动词法”来初步梳理该问题域的领域概念，并获得这些领域概念之间的关系。这种方法由 Russell Abbott 提出，在他 1983 年发表的论文 <em>Program Design by Informal English Description</em> 中，他建议写下问题的英语描述，然后划出名词和动词。名词代表了候选对象，动词代表了这些对象上的候选操作。倘若采用用例分析，则一个用例就是一句英语描述。例如电商系统下订单的用例图如下所示：</p>
-<p><img src="assets/7af77d40-abde-11e9-bd6e-8d1156928a9d" alt="59800642.png" /></p>
+<p><img src="assets/7af77d40-abde-11e9-bd6e-8d1156928a9d" alt="png" /></p>
 <p>用例描述中的名词对应于领域分析模型中的类型或类型的属性。注意，即使是属性，如果该属性表达了一个领域概念，同样应该定义为类型，如“calculate shipping fee”用例中的名词为 Shipping Fee，它是订单（Order）的属性，但它同样体现了“运费”这一个重要的领域概念。用例中的参与者在领域分析模型中同样应该被定义为类型，它与构成主用例宾语的领域概念之间存在关联关系。</p>
 <p>比起用例，用例图要更加精炼。若在领域场景分析过程中，以获得用例图为目标，就可以降低领域分析建模阶段的成本。然而，凡事有利就有弊，这种精炼的形式也可能会漏掉一些必要的业务概念。这些业务概念往往是领域模型中主要领域概念的附属概念，如订单（Order）与订单项（OrderItem）、购物车（ShoppingCart）与购物车选项（CartItem）。</p>
 <p>在分析用例时，也要注意用例描述可能带来的分析陷阱或隐藏的概念。例如“validate inventory”用例中，宾语为库存（Inventory），但在下订单领域场景中，检查的其实是商品的库存量。当然，这也可能反过来说明在绘制用例图时，我们对用例的描述欠妥当。“notify buyer”用例较为特殊，表面上它表达的领域行为就是“通知买家”，但实际上这里隐藏了一个“通知（Notification）”的名词概念。</p>