fix img

专栏/DDD 微服务落地实战/04 领域模型是如何指导程序设计的？.md.html

@@ -165,12 +165,12 @@ function hide_canvas() {
 <p>服务、实体与值对象是领域驱动设计的<strong>基本元素</strong>。然而，要将业务领域模型最终转换为程序设计，还要加入相应的设计。通常，将业务领域模型转换为程序设计，有两种设计思路：<strong>贫血模型</strong>与<strong>充血模型</strong>。</p>
 <h4>贫血模型与充血模型</h4>
 <p>事情是这样的：2004 年，软件大师 Eric Evans 发表了他的不朽著作《领域驱动设计》。虽然已经过去十多年了，这本书直到今天依然对我们有相当大的帮助。接着，另一位软件大师 Martin Fowler 在自己的博客中提出了“<strong>贫血模型</strong>”的概念。这位“马大叔”有一个非常大的特点，那就是软件行业中各种名词都是他发明的，包括如今业界影响巨大的软件重构、微服务，也是他的杰作。然而，马大叔在提出“贫血模型”的时候，却将其作为反模式提出来批评：所谓的“贫血模型”，就是在软件设计中，有很多的 POJO（Plain Ordinary Java Object）对象，它们除了有一堆 get/set 方法，几乎没有任何业务逻辑。这样的设计被称为“贫血模型”。</p>
-<p><img src="assets/Ciqc1F-8wNGAXF-pAAC7CszMUB8535.png" alt="image.png" /></p>
+<p><img src="assets/Ciqc1F-8wNGAXF-pAAC7CszMUB8535.png" alt="png" /></p>
 <p>如上图所示，在领域模型中有 VIP 会员的领域对象，该对象除了有一堆属性以外，还有“会员打折”“会员福利”“会员特权”等方法。如果将该领域模型按照贫血模型进行设计，就会设计一个 VIP 会员的实体对象与 Service，实体对象包含该对象的所有属性，以及这些属性包含的数据；然后，将所有的方法都放入 Service 中，在调用它们的时候，必须将领域对象作为参数进行传输。这样的设计，将领域对象中的这些方法，以及这些方法在执行过程中所需的数据，割裂到两个不同的对象中，打破了对象的封装性。它会带来什么问题呢？</p>
-<p><img src="assets/CgqCHl-8wN-AemLyAAD80XA9jt0166.png" alt="image" /></p>
+<p><img src="assets/CgqCHl-8wN-AemLyAAD80XA9jt0166.png" alt="png" /></p>
 <p>如上图所示，在领域模型中的 VIP 会员通过继承分为了“金卡会员”与“银卡会员”。如果将该领域模型按照贫血模型进行设计，则会设计出一个“金卡会员”的实体对象与 Service，同时设计出一个“银卡会员”的实体对象与 Service。“金卡会员”的实体对象应当调用“金卡会员”的 Service，如果将“金卡会员”的实体对象去调用了“银卡会员”的 Service，系统就会出错。所以，除了进行以上设计以外，还需要有一个客户程序去判断，当前的实体对象是“金卡会员”还是“银卡会员”？这时，系统变更就变得没有那么灵活了。</p>
 <p>比如，现在需要在原有基础上，再增加一个“铂金会员”，那么不仅要增加一个“铂金会员”的实体对象与 Service，还要修改客户程序的判断，系统变更成本就会提高。</p>
-<p><img src="assets/Ciqc1F-8wOmADldnAAC_kd7-7Ts661.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F-8wOmADldnAAC_kd7-7Ts661.png" alt="png" /></p>
 <p>针对贫血模型的问题，马大叔提出了“充血模型”的概念。所谓“充血模型”，就是将领域模型的原貌直接转换为程序中领域对象的设计。这时，各种业务操作就不再在“服务”中实现了，而是在领域对象中实现。如图所示，在程序设计时，既有父类的“VIP 会员”，又有子类“金卡会员”与“银卡会员”。</p>
 <p>但充血模型与贫血模型不同的是：</p>
 <ul>
@@ -193,10 +193,10 @@ function hide_canvas() {
 <p><strong>1. 贫血模型比充血模型更加简单易行</strong></p>
 <p>充血模型是将领域模型的原貌直接映射成了程序设计，因此在程序设计时需要增加更多的诸如仓库、工厂的组件，对设计能力与架构提出了更高的要求。</p>
 <p>譬如，现在要设计一个订单系统，在领域建模时，每个订单需要有多个订单明细，还要对应相关的客户信息、商品信息。因此，在装载一个订单时，需要同时查出它的订单明细，以及对应的客户信息、商品信息，这些需要有强大的订单工厂进行装配；装载订单以后，还需要放到仓库中进行缓存，需要订单仓库具备缓存的能力；此外，在保存订单的时候，还需要同时保存订单和订单明细，并将它们放到一个事务中。所有这些都需要强有力的技术平台的支持。</p>
-<p><img src="assets/Ciqc1F-8wPaAeLA0AACXsgk7a30591.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F-8wPaAeLA0AACXsgk7a30591.png" alt="png" /></p>
 <p>相反，贫血模型就显得更加贫民化。在贫血模型中，<strong>MVC 层</strong>直接调用 Service，Service 通过<strong>DAO</strong>进行数据访问。在这个过程中，每个 DAO 都只查询数据库中的某个表，然后直接交给 Service 去使用，去完成各种处理。</p>
 <p>以订单系统为例，订单有订单 DAO，负责查询订单；订单明细有订单明细 DAO，负责查询订单明细。它们查询出来以后，不需要装配，而是直接交给订单 Service 使用。在保存订单时，订单 DAO 负责保存订单，订单明细 DAO 负责保存订单明细。它们都是通过订单 Service 进行组织，并建立事务。贫血模型不需要仓库，不需要工厂，也不需要缓存，一切都显得那么简单粗暴但一目了然。</p>
-<p><img src="assets/CgqCHl-8wQKAA-qqAACS75JqiHM949.png" alt="image" /></p>
+<p><img src="assets/CgqCHl-8wQKAA-qqAACS75JqiHM949.png" alt="png" /></p>
 <p><strong>2. 充血模型需要具备更强的设计与协作能力</strong></p>
 <p>充血模型的设计实现给开发人员提出了更高的<strong>能力要求</strong>，需要具有更强的 OOA/D（面向对象分析/设计） 能力、分析业务、业务建模与设计能力。譬如，在订单系统这个案例中，开发人员要先进行领域建模，分析清楚该场景中的订单、订单明细、用户、商品等领域对象的关联关系；还要分析各个领域对象在真实世界中都有什么行为，对应到软件设计中都有什么方法，在此基础上再进行设计开发。</p>
 <p>同时，充血模型需要有较强的<strong>团队协作能力</strong>。比如，在该场景中，当订单在进行创建时，需要对用户以及用户地址的相关信息进行查询。此时，订单 Service 不能直接去查询用户和用户地址的相关表，而是去调用用户 Service 的相关接口，由用户 Service 去完成对用户相关表的查询。这时候，开发订单模块的团队，需要向开发用户模块的团队提出接口需求。</p>
@@ -204,7 +204,7 @@ function hide_canvas() {
 <p><img src="assets/Ciqc1F-8wSCAOU-fAAEaUozd6TI978.png" alt="DDD 04--金句.png" /></p>
 <p><strong>3. 贫血模型更容易应对复杂的业务处理场景</strong></p>
 <p>充血模型在进行设计时，是将所有的业务处理过程在领域对象的相应方法中实现的。这样的设计，如果业务处理过程比较简单，还可以从容应对；但如果是面对非常<strong>复杂的业务处理场景</strong>时，就有一些力不从心。在这些复杂的业务处理场景中，如果采用贫血模型，可以将复杂的业务处理场景，划分成多个相对独立的步骤；然后将这些独立的步骤分配给多个 Service 串联起来执行。这样，各个步骤就是以一种松耦合的形式串联地组织在一起，以领域对象作为参数在各个Service 中进行传递。</p>
-<p><img src="assets/CgqCHl-8wQ6AYR90AAA2JpCgIHE892.png" alt="image" /></p>
+<p><img src="assets/CgqCHl-8wQ6AYR90AAA2JpCgIHE892.png" alt="png" /></p>
 <p>在这样的设计中，领域对象既可以作为各个方法调用的输入，又可以作为它们的输出。比如，在上图的案例中，领域对象作为参数首先调用 ServiceA；调用完以后将结果数据写入领域对象的前 5 个字段，传递给 ServiceB；ServiceB 拿到领域对象以后，既可以作为输入去读取前 5 个字段，又可以作为输出将执行结果写入中间 5 个字段；最后，将领域对象传递给 ServiceC，执行完操作以后去写后面 5 个字段；当所有字段都写入完成以后，存入数据库，完成所有操作。</p>
 <p>在这个过程中，如果日后需要变更，要增加一个处理过程，或者去掉一个处理过程，再或者调整它们的执行顺序，都是比较容易的。这样的设计要求处理过程必须在领域对象之外，在 Service 中实现。然而，如果采用的是充血模型的设计，就必须要将所有的处理过程都写入这个领域对象中去实现，无论这些处理过程有多复杂。这样的设计势必会加大日后变更维护的成本。</p>
 <p>所以，不论是贫血模型还是充血模型，它们各有优缺点，到底应当采用贫血模型还是充血模型，争执了这么多年，但我认为它们并不是熊掌和鱼的关系，我们应当把它们<strong>结合起来，取长补短，合理利用</strong>。关键是要先弄清楚它们的差别，也就是业务逻辑应当在哪里实现：贫血模型的业务逻辑在 Service 中实现，但充血模型是在领域对象中实现。清楚了这一点，在今后的软件设计时，可以将那些需要封装的业务逻辑放到领域对象中，按照充血模型去设计；除此之外的其他业务逻辑放到 Service 中，按照贫血模型去设计。</p>