fix img

专栏/领域驱动设计实践（完）/092 子领域与限界上下文.md.html

@@ -534,13 +534,13 @@ function hide_canvas() {
 <p>通常，我们希望将子领域一对一地对应到限界上下文。这种做法显式地将领域模型分离到不同的业务板块中，并将问题空间和解决方案空间融合在一起。在实践中，这种做法并不总是可能的，但通过新的努力，我们是可以做到这一点的。</p>
 </blockquote>
 <p>这里提到的概念包括：领域、子领域（Subdomain）和限界上下文。倘若为子领域和限界上下文建立了一种映射关系，我们可以得出如下关系：</p>
-<p><img src="assets/a6101d30-169a-11ea-8478-cb869aae9121" alt="79270701.png" /></p>
+<p><img src="assets/a6101d30-169a-11ea-8478-cb869aae9121" alt="png" /></p>
 <p>如上的映射关系是否合理呢？我就这一问题请教了 ThoughtWorks 的李新，他说：“简单粗暴的一对多或者一对一都是因为懒于思考。”这是因为子领域属于问题空间中的战略精炼，限界上下文属于解决方案空间战略阶段的模式。二者并无直接的映射关系。如果真的需要确定二者的关系呢？李新谈到：</p>
 <blockquote>
 <p>在实际情况下，一对多或者多对一都是合理的。即一种映射是一个限界上下文<strong>包含</strong>多个子领域，另一种映射是一个子领域<strong>拆分</strong>成多个限界上下文，或者就是简单的一对一关系。不过要小心的是，对于第一种映射，注意我用了<strong>包含</strong>两个字，意味着在这个限界上下文中的任何一个子领域都不能再包含在其他限界上下文中。而对第二种映射，注意我用了<strong>拆分</strong>两个字，意味着，这个子领域中的任何一个限界上下文都不能包含其他子领域。只要上面的原则不违背，两种映射都没有问题。</p>
 </blockquote>
 <p>ThoughtWorks 的肖然对此问题有着自己的理解，他在文章《<a href="https://insights.thoughtworks.cn/subdomain-and-bounded-context/">当子领域遇见限界上下文</a>》中首先高屋建瓴地从战略、战术、问题、解决方案四个象限对领域驱动设计的主要概念做了一个概况性的归类：</p>
-<p><img src="assets/b8c27db0-169a-11ea-981f-cdaafe390fdd" alt="0.8312504613189953.png" /></p>
+<p><img src="assets/b8c27db0-169a-11ea-981f-cdaafe390fdd" alt="png" /></p>
 <p>肖然在这篇文章比较了 Vaughn Vernon、事件风暴的发明者 Alberto Brandolini 和他自己的观点：</p>
 <ul>
 <li>Vaughn Vernon：一直以来的实践方式隐含着一对一的对应关系</li>
@@ -548,7 +548,7 @@ function hide_canvas() {
 <li>肖然：认为一对多的映射是最优的选择</li>
 </ul>
 <p>ENode 框架的作者汤雪华用<a href="https://www.cnblogs.com/netfocus/p/DDD.html">一幅图</a>表达了问题空间和解决方案空间诸概念之间的关系：</p>
-<p><img src="assets/e996f2e0-169a-11ea-8478-cb869aae9121" alt="0.4852040409131759.png" /></p>
+<p><img src="assets/e996f2e0-169a-11ea-8478-cb869aae9121" alt="png" /></p>
 <p>汤雪华认为在问题空间关注的是领域，并将其划分为多个子领域（或者说子域）。每个子领域由业务模型构成，它们是分析阶段的产物。通过抽象和精炼，每个子领域中的业务模型又映射为解决方案中子解决方案（即限界上下文）的领域模型。得到的领域模型和技术架构则属于设计阶段的产物。</p>
 <p>显然，针对子领域和限界上下文之间的关系，真可以说是众说纷纭，互相矛盾。真理不仅没有越辩越明，反而让人变得更糊涂了。我认为，要把这两个概念之间的关系分辨清楚，需要来一个追本溯源。</p>
 <h4>追本溯源</h4>
@@ -558,7 +558,7 @@ function hide_canvas() {
 <p>创建支撑子领域的原因在于他们专注于业务的某个方面，否则，如果一个子领域被用于整个业务系统，那么这个子领域便是通用子领域。我们并不能说支撑子领域和通用子领域是不重要的，他们是重要的，只是我们对他们的要求并不像核心领域那么高。</p>
 </blockquote>
 <p>由此可以看出，虽然 Eric Evans 并没有明确提出“子领域”的概念，但实则核心领域与通用子领域就是对领域的一种划分，只是 Vaughn Vernon 在此基础上将其明确化了，并进一步细分了子领域的类别。为了保证概念的一致性，我统一将子领域称之为核心子领域（Core Subdomain，Eric Evans 称为核心领域）、支撑子领域（Supporting Subdomain）和通用子领域（Generic Subdomain），它们彼此的关系如下图所示：</p>
-<p><img src="assets/29934240-169b-11ea-981f-cdaafe390fdd" alt="79202548.png" /></p>
+<p><img src="assets/29934240-169b-11ea-981f-cdaafe390fdd" alt="png" /></p>
 <p>在确定了“子领域”这个概念后，我们再来分析 Eric Evans 提出它的根本原因。他在《精炼》一章中写道：</p>
 <blockquote>
 <p>如何才能专注于核心问题而不被大量的次要问题淹没呢？分层架构可以把领域概念从技术逻辑中（技术逻辑确保了计算机系统能够运转）分离出来，但在大型系统中，即使领域被分离出来，它的复杂性也可能仍然难以管理。</p>