fix img

专栏/领域驱动设计实践（完）/003 领域驱动设计概览.md.html

@@ -533,7 +533,7 @@ function hide_canvas() {
 <h3>领域驱动设计过程</h3>
 <p>领域驱动设计当然不是架构方法，也并非设计模式。准确地说，它其实是“一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发”。领域驱动设计贯穿了整个软件开发的生命周期，包括对需求的分析、建模、架构、设计，甚至最终的编码实现，乃至对编码的测试与重构。</p>
 <p>领域驱动设计强调领域模型的重要性，并通过模型驱动设计来保障领域模型与程序设计的一致。从业务需求中提炼出统一语言（Ubiquitous Language），再基于统一语言建立领域模型；这个领域模型会指导着程序设计以及编码实现；最后，又通过重构来发现隐式概念，并运用设计模式改进设计与开发质量。这个过程如下图所示：</p>
-<p><img src="assets/2b047ae0-7854-11e8-9ada-255ab1257678" alt="enter image description here" /></p>
+<p><img src="assets/2b047ae0-7854-11e8-9ada-255ab1257678" alt="png" /></p>
 <p>这个过程是一个覆盖软件全生命周期的设计闭环，每个环节的输出都可以作为下一个环节的输入，而在其中扮演重要指导作用的则是“领域模型”。这个设计闭环是一个螺旋式的迭代设计过程，领域模型会在这个迭代过程中逐渐演进，在保证模型完整性与正确性的同时，具有新鲜的活力，使得领域模型能够始终如一的贯穿领域驱动设计过程、阐释着领域逻辑、指导着程序设计、验证着编码质量。</p>
 <p>如果仔细审视这个设计闭环，会发现在针对问题域和业务期望提炼统一语言，并通过统一语言进行领域建模时，可能会面临高复杂度的挑战。这是因为对于一个复杂的软件系统而言，我们要处理的问题域实在太庞大了。在为问题域寻求解决方案时，需要从宏观层次划分不同业务关注点的子领域，然后再深入到子领域中从微观层次对领域进行建模。宏观层次是战略的层面，微观层次是战术的层面，只有将战略设计与战术设计结合起来，才是完整的领域驱动设计。</p>
 <h4>战略设计阶段</h4>
@@ -558,13 +558,13 @@ function hide_canvas() {
 <li>应用服务（Application Service）</li>
 </ul>
 <p>Eric Evans 通过下图勾勒出了战术设计诸要素之间的关系：</p>
-<p><img src="assets/41040a90-7854-11e8-9ada-255ab1257678" alt="enter image description here" /></p>
+<p><img src="assets/41040a90-7854-11e8-9ada-255ab1257678" alt="png" /></p>
 <p>领域驱动设计围绕着领域模型进行设计，通过<strong>分层架构（Layered Architecture）<strong>将领域独立出来。表示领域模型的对象包括：<strong>实体</strong>、<strong>值对象</strong>和</strong>领域服务</strong>，<strong>领域逻辑都应该封装在这些对象中</strong>。这一严格的设计原则可以避免业务逻辑渗透到领域层之外，导致技术实现与业务逻辑的混淆。在领域驱动设计的演进中，又引入了<strong>领域事件</strong>来丰富领域模型。</p>
 <p><strong>聚合</strong>是一种边界，它可以封装一到多个<strong>实体</strong>与<strong>值对象</strong>，并维持该边界范围之内的业务完整性。在聚合中，至少包含一个实体，且只有实体才能作为<strong>聚合根（Aggregate Root）</strong>。注意，在领域驱动设计中，没有任何一个类是单独的聚合，因为聚合代表的是边界概念，而非领域概念。在极端情况下，一个聚合可能有且只有一个实体。</p>
 <p><strong>工厂</strong>和<strong>资源库</strong>都是对领域对象生命周期的管理。前者负责领域对象的创建，往往用于封装复杂或者可能变化的创建逻辑；后者则负责从存放资源的位置（数据库、内存或者其他 Web 资源）获取、添加、删除或者修改领域对象。领域模型中的资源库不应该暴露访问领域对象的技术实现细节。</p>
 <h4>演进的领域驱动设计过程</h4>
 <p>战略设计会控制和分解战术设计的边界与粒度，战术设计则以实证角度验证领域模型的有效性、完整性与一致性，进而以演进的方式对之前的战略设计阶段进行迭代，从而形成一种螺旋式上升的迭代设计过程，如下图所示：</p>
-<p><img src="assets/5d450330-7854-11e8-974f-33e8b8ec2777" alt="enter image description here" /></p>
+<p><img src="assets/5d450330-7854-11e8-974f-33e8b8ec2777" alt="png" /></p>
 <p>面对客户的业务需求，由领域专家与开发团队展开充分的交流，经过需求分析与知识提炼，以获得清晰的问题域。通过对问题域进行分析和建模，识别限界上下文，利用它划分相对独立的领域，再通过上下文映射建立它们之间的关系，辅以分层架构与六边形架构划分系统的逻辑边界与物理边界，界定领域与技术之间的界限。之后，进入战术设计阶段，深入到限界上下文内对领域进行建模，并以领域模型指导程序设计与编码实现。若在实现过程中，发现领域模型存在重复、错位或缺失时，再进而对已有模型进行重构，甚至重新划分限界上下文。</p>
 <p>两个不同阶段的设计目标是保持一致的，它们是一个连贯的过程，彼此之间又相互指导与规范，并最终保证<strong>一个有效的领域模型和一个富有表达力的实现同时演进</strong>。</p>
 </div>