fix img

专栏/领域驱动设计实践（完）/011 建立统一语言.md.html

@@ -540,7 +540,7 @@ function hide_canvas() {
 <p>某些领域术语是有行业规范的，例如财会领域就有标准的会计准则，对于账目、对账、成本、利润等概念都有标准的定义，在一定程度上避免了分歧。然而，标准并非绝对的，在某些行业甚至存在多种标准共存的现象。以民航业的运输统计指标为例，牵涉到与运量、运力以及周转量相关的术语，就存在 ICAO（International Civil Aviation Organization，国际民用航空组织）与IATA（International Air Transport Association，国际航空运输协会）两大体系，而中国民航局又有自己的中文解释，航空公司和各大机场亦有自己衍生的定义。</p>
 <p>例如，针对一次航空运输的运量，就要分为<strong>城市对</strong>与<strong>航段</strong>的运量统计。<strong>城市对运量</strong>统计的是出发城市到目的城市两点之间的旅客数量，机场将其称之为<strong>流向</strong>。ICAO 定义的领域术语为 <strong>City-pair（OFOD）</strong>，而 IATA 则命名为 <strong>O &amp; D</strong>。<strong>航段运量</strong>又称为<strong>载客量</strong>，指某个特定航段上所承载的旅客总数量，ICAO将其定义为 <strong>TFS（Traffic by flight stage）</strong>，而 IATA 则称为 <strong>Segment Traffic</strong>。</p>
 <p>即使针对<strong>航段运量</strong>这个术语，我们还需要明确地定义这个运量究竟指的是<strong>载客量</strong>，还是包含了该航段上承载的全部旅客、货物与邮件数量；我们还需要明确<strong>城市对</strong>与<strong>航段</strong>之间的区别，它们在指标统计时，实则存在细微的差异，一不小心忽略，结果就可能谬以千里。以航班 CZ5724 为例，该航班从北京（目的港代码 PEK）出发，经停武汉（目的港代码 WUH）飞往广州（目的港代码 CAN）。假定从北京到武汉的旅客数为 105，从北京到广州的旅客数为 14，从武汉到广州的旅客数为 83，则统计该次航班的<strong>城市对运量</strong>，应该分为三个城市对分别统计，即统计 PEK-WUH、PEK-CAN、WUH-CAN。而<strong>航段运量</strong>的统计则仅仅分为两个航段 PEK-WUH 与 WUH-CAN，至于从北京到广州的 14 名旅客，这个数量值则被截分为了两段，分别计数，如下图所示：</p>
-<p><img src="assets/6f680680-7a79-11e8-ae51-d5fb97616c42" alt="enter image description here" /></p>
+<p><img src="assets/6f680680-7a79-11e8-ae51-d5fb97616c42" alt="png" /></p>
 <p>显然，如果我们不明白城市对运量与航段运量的真正含义，就可能混淆这两种指标的统计计算规则。这种术语理解错误带来的缺陷往往难以发现，除非业务分析人员、开发人员与测试人员能就此知识达成一致的正确理解。</p>
 <p>在领域建模过程中，我们往往需要在文档中建立一个大家一致认可的术语表。术语表中需要包括整个团队精炼出来的术语概念，以及对该术语的清晰明白的解释。若有可能，可以为难以理解的术语提供具体的案例。该术语表是领域建模的关键，是模型的重要参考规范，能够真实地反应模型的领域意义。一旦发生变更，也需要及时地对其进行更新。</p>
 <p><strong>在维护领域术语表时，一定需要给出对应的英文术语，否则可能直接影响到代码实现</strong>。在我们的一个产品开发中，根据需求识别出了“导入策略”的领域概念。由于这个术语非常容易理解，团队就此达成了一致，却没有明确给出英文名称，最后导致前端和后端在开发与“导入策略”有关的功能时，分别命名为 ImportingPolicy 与 ImportingStrategy，人为地制造了混乱。</p>