fix img

专栏/领域驱动设计实践（完）/091 领域驱动设计体系.md.html

@@ -420,7 +420,7 @@ function hide_canvas() {
                         <div><h1>091 领域驱动设计体系</h1>
 <p>至此，我已经将领域驱动战略设计和战术设计的内容全部讲解完毕。从统一语言到限界上下文，从限界上下文到上下文映射，从领域分析建模到领域设计建模，再从领域设计建模到领域实现建模，我将软件架构设计、面向对象设计、场景驱动设计和测试驱动开发有机地融合起来，贯穿于领域驱动设计的全过程。这个过程牵涉到了大量的分析建模、软件设计和编程实现知识，许多原则、模式和实践本身就是互为参考的，这就不可避免导致内容存在一定的发散性，无法清晰地展现领域驱动设计的全貌。此外，战略设计与战术设计并非完全割裂的两个阶段，战略设计的结果指导着战术设计，战术设计的决策又反过来影响战略设计，二者互为补充，只有如此才能形成一个螺旋迭代的领域驱动设计过程。</p>
 <p>在进行战略设计与战术设计的融合讲解时，让我们先回顾在《领域驱动战略设计实践》中给出的领域驱动设计全过程：</p>
-<p><img src="assets/36210960-1516-11ea-a572-8bd4a271a05d" alt="e979f08c-1cba-4b10-ad05-e575e71e6b3c.png" /></p>
+<p><img src="assets/36210960-1516-11ea-a572-8bd4a271a05d" alt="png" /></p>
 <p>整个过程总结为如下一段话：</p>
 <blockquote>
 <p>面对客户的业务需求，由领域专家与开发团队展开充分的交流，经过需求分析与知识提炼，获得清晰的问题域。通过对问题域进行分析和建模，识别限界上下文，利用它划分相对独立的领域，再通过上下文映射建立它们之间的关系，辅以分层架构与六边形架构划分系统的逻辑边界与物理边界，界定领域与技术之间的界限。之后，进入战术设计阶段，深入到限界上下文内对领域进行建模，并以领域模型指导程序设计与编码实现。若在实现过程中，发现领域模型存在重复、错位或缺失时，再进而对已有模型进行重构，甚至重新划分限界上下文。</p>
@@ -454,7 +454,7 @@ function hide_canvas() {
 <li>Z 维度：每个抽象层次针对业务、技术和管理三个方面需要思考和分析的关注点，包括方法、模式与工件。</li>
 </ul>
 <p>如果将整个软件系统视为一个正方体，它被 X 轴、Y 轴和 Z 轴三个维度切割，恰似一个可以任意转动的魔方一般，因而我将这套体系称之为“<strong>领域驱动设计魔方</strong>”。X 维度限定领域驱动设计的内容，Y 维度分离领域驱动设计的层次，Z 维度蕴含了领域驱动设计的实践，由此站在全方位的角度融合了领域驱动的战略设计与战术设计，但又不至于过分地夸大领域驱动设计的作用，依旧将整个过程控制在领域驱动设计的范畴中：</p>
-<p><img src="assets/76173e40-1516-11ea-9a65-47da06f19b9d" alt="179d720d-622a-4456-83e8-dbcd8faedc18.jpg" /></p>
+<p><img src="assets/76173e40-1516-11ea-9a65-47da06f19b9d" alt="png" /></p>
 <p>下面，我将根据宏观、微观和纳米三个抽象层次，依次对这个魔方体系进行讲解。</p>
 <h4>宏观层次</h4>
 <p>宏观层次是针对整个软件系统开展的战略宏图规划与战略概要设计，通常分为两个阶段：全局分析阶段与战略设计阶段。全局分析阶段是问题定义与分析阶段，主要目的就是明确系统的愿景与目标，确定业务问题、技术风险和管理挑战，通过全局调研与战略分析，从宏观角度确定整个系统在业务、技术与管理方面的战略目标、指导原则，为战略设计提供有价值的输出。战略设计阶段是概念模型的构建阶段，针对问题域寻找和确定宏观层面的解决方案，获得系统的业务逻辑架构和物理架构，确定需求管理体系、进度管理流程和团队管理制度，使得这些管理体系能够与领域驱动设计形成合力，满足领域驱动设计的前置条件。</p>
@@ -498,7 +498,7 @@ function hide_canvas() {
 <li>工件：确定项目管理流程与开发流程，制定发布计划，确定史诗故事与主故事列表</li>
 </ul>
 <p>遵循典型的领域驱动设计，宏观层次的魔方切面如下图所示：</p>
-<p><img src="assets/9f2a3a30-1516-11ea-ba1f-dd9f5b653de6" alt="d128867c-a202-42dc-b8da-30261acf964a.png" /></p>
+<p><img src="assets/9f2a3a30-1516-11ea-ba1f-dd9f5b653de6" alt="png" /></p>
 <p>在宏观层次，通过引入<strong>业务架构</strong>的设计思想与方法体系，通过价值流帮助我们更加准确地确定符合企业战略方向的<strong>核心领域</strong>，在获得包含了史诗故事与主故事的<strong>业务全景分析文档</strong>后，通过<strong>事件风暴</strong>进行全景业务分析，获得<strong>限界上下文</strong>并确定<strong>上下文映射</strong>，输出<strong>业务战略设计文档</strong>。技术方面，在<strong>整洁架构</strong>思想的指导下，利用 <strong>RAID 风暴</strong>识别风险、假设、问题和依赖，由此获得<strong>架构全局分析文档</strong>，从而确定架构风格，例如选择<strong>微服务架构风格</strong>，并利用 <strong>RUP 4+1 视图</strong>界定业务逻辑视图和应用物理视图等多个视图之间的关系，形成<strong>架构战略设计文档</strong>。整个过程在<strong>精益需求管理体系</strong>和敏捷项目管理流程如 <strong>Scrum</strong> 中的管控下进行，并根据<strong>康威定律</strong>组建<strong>特性团队</strong>。通常，宏观层次的实践活动都属于<strong>项目先启</strong>阶段，在这个阶段，通过引入精益管理思想的 MVP 与<strong>故事地图</strong>，获得整个系统开发的<strong>发布计划</strong>。</p>
 <h4>微观层次</h4>
 <p>如果说宏观层次的活动更偏重于战略规划与设计，微观层次的活动就是对战略规划与设计做进一步梳理和细化，对领域模型进行深化设计，进一步评估技术风险对整体业务架构带来的影响，从而给出可行的设计方案，继续梳理和细化需求，确定每个特性团队的迭代任务。它是承上启下的关键环节，是领域驱动设计在团队中落地的重要前提，这个层次输出的工件可以为团队成员提供直接的指导与参考价值。</p>
@@ -524,7 +524,7 @@ function hide_canvas() {
 <li>输出：用户故事列表、迭代计划、技术雷达图、能力雷达图</li>
 </ul>
 <p>微观层次的典型领域驱动设计魔方切面如下图所示：</p>
-<p><img src="assets/cb8f6e60-1516-11ea-8833-c12ffd837eb2" alt="afb48159-75c0-4960-90c5-11c69a2a4125.png" /></p>
+<p><img src="assets/cb8f6e60-1516-11ea-8833-c12ffd837eb2" alt="png" /></p>
 <p>在确定了全局分析和战略设计方案之后，通过<strong>事件风暴</strong>确定领域分析模型，然后利用<strong>场景驱动设计</strong>将领域行为分配给对应的<strong>角色构造型</strong>，获得更为详细的领域设计模型，这两个模型共同构成了<strong>模型设计文档</strong>；技术方面，利用<strong>服务模型驱动设计</strong>定义各个限界上下文对外公开的服务接口，并撰写<strong>服务接口定义文档</strong>。团队以及团队之间的交流协作都应遵循这个阶段制定的<strong>迭代计划</strong>，在 <strong>Scrum</strong> 的迭代周期内完成。团队通过<strong>用户故事</strong>体现需求，通过<strong>看板</strong>跟踪迭代进度。</p>
 <p>注意，从微观层次到纳米层次绝对不是一个瀑布式的开发流程。一旦进入 Scrum 的迭代（Sprint）阶段，微观层次的场景驱动设计与纳米层次的测试驱动开发其实是融合在一起的。针对同一个需求存在设计与开发的先后关系，但整个迭代开发却不存在泾渭分明的这两个阶段。</p>
 <h4>纳米层次</h4>
@@ -551,7 +551,7 @@ function hide_canvas() {
 <li>输出：进度燃烧图或燃尽图、回顾会议待办项</li>
 </ul>
 <p>纳米层次的领域驱动设计魔方切面如下图所示：</p>
-<p><img src="assets/ec9a2410-1516-11ea-b5c1-dd5e7e6c91fb" alt="e1593d16-ea7d-44aa-897d-e6d70ec1fc54.png" /></p>
+<p><img src="assets/ec9a2410-1516-11ea-b5c1-dd5e7e6c91fb" alt="png" /></p>
 <p><strong>测试驱动开发</strong>的过程需要在<strong>简单设计</strong>思想的指导下进行，输出<strong>领域模型代码</strong>，即与领域模型有关的产品代码和测试代码。在纳米层次，业务与技术的融合更加密切，由于在微观层次已经做出技术决策，确定了实现基础设施的框架选型，因此针对基础设施层的实现，主要的开发工作就是<strong>框架应用开发</strong>，其中，与领域驱动设计密切相关的是基于 <strong>ORM</strong> 框架的应用开发，以及必要的<strong>事务处理</strong>功能，从而输出<strong>基础设施代码</strong>。基础设施代码除了提供了基础设施层的实现外，还包含对应的集成测试代码、契约测试代码以及运维脚本。在管理方面，仍需按照 <strong>Scrum</strong> 流程开展迭代的增量开发。为了加强需求、开发、测试等角色之间的交流，可以引入诸如 Kick Off 与 Desk Check 等迭代实践，最终的进度情况可以通过<strong>燃尽图</strong>或者<strong>燃烧图</strong>来表示。</p>
 <p>虽然领域驱动设计以<strong>业务</strong>为主，但业务与技术、管理是互相影响的。领域驱动设计魔方以领域驱动设计方法论为中心，将有利于领域驱动设计的诸多方法、模式与实践整合进来，形成了多层次、多维度、多角度的整体知识体系。虽然我在讲解这一体系时，是自顶向下沿着宏观层次、微观层次到纳米层次逐一展开，但整个领域驱动设计过程始终还是迭代的、螺旋上升的。领域驱动设计魔方并非表达一个动态的驱动设计过程，而是建立了一个静态的多层次知识体系，可以作为企业或组织实施领域驱动设计的参考模型。</p>
 </div>