fix img

专栏/领域驱动设计实践（完）/043 案例 培训管理系统.md.html

@@ -543,7 +543,7 @@ function hide_canvas() {
 <p>深化实体关系模型，需要确定数据表以及数据表之间的关系和属性，由此获得数据项模型，这需要继续深挖业务需求，由此获得数据实体的属性，并按照数据库范式对实体进行拆分，并合理安排数据表之间的关系。例如，针对课程实体，可以将其拆分为课程（Course）、日程（Calendar）与类别（Category）表。课程与日程、类别的关系是一对多的关系。针对订单实体，可以将其拆分为订单（Order）和订单项（OrderItem）。</p>
 <p>数据项模型的主体是数据表以及数据表之间的关系。在培训系统中，我们欣喜地发现数据模型中的关系表不仅在于消除表之间的多对多关系，同时还体现了业务概念。例如，期望列表（WishList）体现了学生与课程之间的多对多关系，培训（Training）同样体现了这二者之间的多对多关系。</p>
 <p>在梳理数据表之间的关系时，有时候会因为建立了更细粒度的数据表，而判断出之前的实体关系可能存在谬误。例如实体关系模型为支付（Payment）与培训、订单与培训之间建立了关系，但在数据项模型中，由于引入了订单项，它与培训存在一对一关系，从而解除了订单与培训之间的关系。在定义了支付的属性后，最终发现为支付与培训之间建立关系是没有意义的。最终，我们建立的数据项模型如下图所示：</p>
-<p><img src="assets/9ffb3ef0-8b23-11e9-8ada-d1fb8c4d56bd" alt="79456155.png" /></p>
+<p><img src="assets/9ffb3ef0-8b23-11e9-8ada-d1fb8c4d56bd" alt="png" /></p>
 <h3>建立数据设计模型</h3>
 <p>在数据设计模型中，需要定义持久化对象、数据访问对象与服务对象。为简便起见，本例不考虑各个数据表增删改查的数据管理操作，而只需要设计如下业务功能：</p>
 <ul>
@@ -555,7 +555,7 @@ function hide_canvas() {
 </ul>
 <p>服务将完成这些业务功能。通常，我们需要根据业务功能所要操作的表来判断功能的承担者。例如“学生添加课程到期望列表”操作的是期望列表，这个功能就应该定义到 WishListService 服务中。要注意区分功能描述的概念名词与实际操作数据表的区别。例如，“学生预订课程”功能表面上是操作课程数据表，实际生成了一个培训和订单；“学生购买课程”表面上是操作课程数据表，但实际上是针对订单表和支付表进行操作，这两个功能就应该定义到 OrderService 服务中。</p>
 <p>数据项模型中的每个数据表对应每个持久化对象，这些持久化对象本质上都是传输对象，仅提供业务操作的数据，不具备业务行为。访问数据库的行为都放在持久化对象对应的数据访问对象中，业务行为则由服务来封装。因此，针对以上业务功能得到的设计模型如下所示：</p>
-<p><img src="assets/c794e150-8b23-11e9-ae6c-75b709235ff6" alt="79894111.png" /></p>
+<p><img src="assets/c794e150-8b23-11e9-ae6c-75b709235ff6" alt="png" /></p>
 <p>这里，我使用了 UML 类图来表达数据设计模型，这样可以清晰地看到服务、数据访问对象与持久化对象之间的关系。例如 OrderService 依赖于 PayService、PaymentMapper、OrderMapper、TrainingMapper 和 OrderItemMapper，这些 Mapper 对象又各自依赖于对应的持久化对象。以 Mapper 结尾的对象扮演数据访问对象的角色，之所以这样命名，是沿用了 MyBatis 框架推荐的命名规范。选择 ORM 框架属于设计决策，仍然属于数据建模设计活动的一部分，而这个决策不仅会对设计模型带来影响，同时还会直接影响实现模型。</p>
 <p>在定义数据设计模型时，还需要理清持久化对象之间的关联关系。数据表之间的关联关系往往通过主外键建立，例如在数据项模型中，t_course 表的主键为 id，在 t_wish_list 与 t_calendar 等表中则以 courseId 外键体现关联关系。在对象模型中，通常会通过对象引用的组合方式体现关联关系，如设计模型中 Order 与 OrderItem 之间的组合关系，Category、Teacher 和 Calendar 之间的组合关系。</p>
 <h3>建立数据实现模型</h3>