fix img

专栏/领域驱动设计实践（完）/030 实践 先启阶段的需求分析.md.html

@@ -672,7 +672,7 @@ function hide_canvas() {
 <h4>优先级权衡</h4>
 <p>在面对客户源源不断提出的需求时，最难做出决策的是确定这些需求的优先级。如果是业务需求，我们应该基于系统的业务期望与愿景，判断这些业务需求与实现该愿景的关联程度，并以此来作为优先级的衡量标准。如果是质量属性又或者是管理上的要求，就需要客户和我们一起给出高屋建瓴般的权衡标准。</p>
 <p>一种比较好的实践是采用所谓的“价值滑条（Value Slider）”，即基于该需求协商谈判的可能性高低，列出所有的质量属性需求与管理要求，由客户来做出判断。若协商谈判的可能性高，则说明该需求是可以协商的，可以做出让步的，则滑条向左，意味着优先级低；若协商谈判的可能性低，就说明不可商量，没有妥协的余地，滑条向右，意味着优先级高。在由客户确定每条需求处于这个“价值滑条”的位置时，有一个约束是：任何两个或两个以上的需求对应的滑条都不能出现在同一列上，如下图所示：</p>
-<p><img src="assets/2c71ac10-c32a-11e8-8334-c3a1e643fbf9" alt="enter image description here" /></p>
+<p><img src="assets/2c71ac10-c32a-11e8-8334-c3a1e643fbf9" alt="png" /></p>
 <p>如果需求对应的滑条可能出现在同一列，就需要客户做出权衡和决策，强迫他们移动滑条的位置，这就意味着调整了它们的优先级。上图作为 EAS 的“价值滑条”，意味着我们必须在规定的“最终期限”交付可用的产品，但是我们可以根据对功能的排期，优先实现高优先级的主要功能，同时也可以在人力不足或周期紧张的情况下，增加人手，并适度降低产品质量。</p>
 <h4>对问题域的共同理解</h4>
 <p>在先启阶段，对问题域（Problem Solution）的识别其实就是对客户痛点的识别。之所以要开发这个软件，目的就是解决这些痛点，为应对这些问题提供具有业务价值的功能。在识别痛点的过程中，需要<strong>始终从业务期望与愿景出发</strong>，与不同的利益相关人进行交流，如此才能达成对问题域的共同理解。</p>
@@ -692,7 +692,7 @@ function hide_canvas() {
 <p>除了这些核心子领域外，诸如组织结构、认证与授权都属于通用的子领域，每个核心子领域都需要调用这些子领域提供的功能。注意，通用子领域提供的功能虽然不是系统业务的核心，但缺少这些功能，业务却无法流转。之所以没有将其识别为核心子领域，实则是通过对问题域的理解分析得来。例如，组织结构管理是保证业务流程运转以及员工管理的关键，用户的认证与授权则是为了保证系统的访问安全，但它并没有直接对“供需平衡”这一业务愿景提供业务价值，在前面的痛点分析中，它们也不是利益相关人亟待解决的痛点。</p>
 <p>在分辨系统的利益相关人时，服务中心作为参与 EAS 的业务部门，主要是为项目及项目人员提供工位和硬件资源。它要解决的是资源分配的问题，虽然在某种程度上可以降低运营成本，但却与我们确定的业务愿景没有直接的关系。因此我们将该子域作为一种支撑子领域。</p>
 <p>通过先启阶段对客户痛点的分析，我们形成了对 EAS 问题域的共同理解：</p>
-<p><img src="assets/42efba90-c32a-11e8-8334-c3a1e643fbf9" alt="enter image description here" /></p>
+<p><img src="assets/42efba90-c32a-11e8-8334-c3a1e643fbf9" alt="png" /></p>
 <h5>问题域对统一语言的影响</h5>
 <p>当我们在分辨<strong>市场需求管理</strong>这个问题域时，我们认为有几个领域概念是模糊不清的，即合同（Contract）、市场需求（Market Requirement）、客户需求（Client Requirement），它们三者之间的关系是什么？究竟有什么样的区别？如果不为它们建立一个达成一致共识的统一语言，就有可能影响该问题域的领域模型。</p>
 <p>通过与市场部员工的交流，我们发现市场部对这些概念也是模糊不清的，甚至在很多场景中交替使用了这些概念，而没有一个清晰的定义。在与市场部人员的交谈过程中，他们有时候还提到了“市场需求订单”这个概念。例如，在描写市场需求时，他们会提到“录入市场需求”，但同时又会提到“跟踪市场需求订单”和“查询市场需求订单”。在讨论“客户需求”时，他们提到需要为其指定“承担者”，而在讨论“市场需求”时，却从未提及这一功能。这似乎是“客户需求”与“市场需求”之间的区别。对于“合同”的理解，他们一致认为这是一个法律概念，等同于集团或子公司作为乙方和作为甲方的客户签订的合作协议，并以合同要件的形式存在。</p>
@@ -707,20 +707,20 @@ function hide_canvas() {
 <p>我们仍然保留了“合同”的概念。“合同”领域概念与现实世界的“合同”法律概念相对应，它与订单存在相关性，但本质上并不相同。例如，一个订单中的每个客户需求可以由不同的子公司来承担（Owner），但合同却需要明确甲方和乙方。订单并没有合同需要的那些法律条款。未签订的合同内容确实有很大部分来自订单的内容，但也只是其中商务合作内容的一部分而已。在确定了订单后，市场部人员可以跟踪订单的状态，并且在订单状态发生变更时，修改对应的合同状态。显然，合同的状态与订单的状态并不一致。</p>
 <p>在我们引入“订单”这个概念后，市场需求管理这个问题域就发生了细微的变化。我们可以将这个问题域更名为订单，也可以将订单领域概念视为解决方案域的组成部分，继续保留市场需求管理这个问题域，而将订单视为限界上下文。</p>
 <p>在先启阶段，我们不一定需要领域建模。不过，当我们在识别问题域时发现领域概念无法形成统一语言时，确实可以就领域概念的定义展开讨论与分析。若发现仍有不清晰的地方，就可以通过可视化的领域模型来打消开发团队与领域专家包括客户在概念认知上的不一致。例如，我们针对市场需求问题域建立了如下的领域模型：</p>
-<p><img src="assets/5546b4a0-c32a-11e8-a79d-27388006ab48" alt="enter image description here" /></p>
+<p><img src="assets/5546b4a0-c32a-11e8-a79d-27388006ab48" alt="png" /></p>
 <p>这个领域模型非常清晰地表达了订单（Order）与客户需求（Client Requirement）的一对多关系，且客户需求是放在了订单的聚合边界内。合同（Contract）是一个单独的领域概念，但它与订单存在一个弱关联关系。市场需求（Market Requirment）在通过评估（Assessment）后它会成为订单的一个输入，转换为客户需求。在这个领域模型中，我们可以直观地看到客户需求需要指定承担者（Owner），同时订单还会和客户关系管理问题域中的客户（Client）产生关联。显然，这样清晰表达的领域模型有助于我们和领域专家（客户）的沟通，进而针对这些领域概念达成共识，形成统一语言。</p>
 <h4>确定项目的业务范围</h4>
 <p>之所以要确定项目的业务范围，是为了明确整个系统的边界。明确系统边界是架构设计的重要前提，它一方面可以明确职责划分，了解哪些内容才属于领域驱动设计的范畴；另一方面则可以事先明确当前系统需要与哪些外部系统集成。</p>
 <p>EAS 是软件集团公司的信息化平台，但这个信息化平台是为了解决项目开发的“供需平衡”，因此它围绕着市场需求、人力资源和项目开发为需求主线，其他的信息化产品，如办公自动化（OA）系统、财务系统、工资结算系统等都会作为外部系统与 EAS 的功能集成。明确了这样的业务范围有助于我们甄别需求的边界，并做到功能的收敛。在识别系统的史诗级故事与主故事时，也应该确保这个业务范围边界，同时这个业务范围还会影响到发布与迭代计划的制订。</p>
 <p>确定项目的业务范围还有助于架构层面的考量，通常，我建议引入 C4 模型的系统上下文（System Context）来体现系统的边界。EAS 的系统上下文如下所示：</p>
-<p><img src="assets/67758d40-c32a-11e8-a79d-27388006ab48" alt="enter image description here" /></p>
+<p><img src="assets/67758d40-c32a-11e8-a79d-27388006ab48" alt="png" /></p>
 <p>确定了系统上下文后，可以为后续的上下文映射提供重要参考，如上图所示的 OA 系统、财务系统与工资结算系统可以被视为第三方服务而与 EAS 的限界上下文产生协作。依赖的方向决定了我们选择上下文协作的模式。而系统上下文中的考勤机则会作为 EAS 访问的外部资源，需得做好系统与该机器设备的抽象与隔离。</p>
 <h4>确定业务流程</h4>
 <p>在明确了系统的业务愿景，并就问题域达成共同理解后，我们还需要让主要的业务功能“动”起来。这就需要确定业务流程，因为它可以更好地体现完整全面的领域场景，突出参与者（部门）与用例之间的协作。</p>
 <p>在先启阶段，没有必要将整个系统的所有业务流程都绘制出来，重点是抓住体现业务愿景这个核心价值的主流程。既然 EAS 以“人力资源的供需平衡”为关注核心，因此所有参与方需要执行的主要功能都与该核心价值有关。通过梳理需求，开发团队在与客户充分交流后，<strong>抽象出需求方、供应方这两个核心参与者</strong>，从而绘制出供需双方的协作示意图：</p>
-<p><img src="assets/77715940-c32a-11e8-8334-c3a1e643fbf9" alt="enter image description here" /></p>
+<p><img src="assets/77715940-c32a-11e8-8334-c3a1e643fbf9" alt="png" /></p>
 <p>这个协作示意图非常清晰地体现了需求与供应之间的关系，展现了这个核心流程的关键环节。注意，这个协作示意图并非项目开始之前的当前状态（As-Is），而是期望解决供需平衡问题的将来状态（To-Be）。这种协作关系正好体现了打破部门之间信息壁垒的愿望。由此，我们就可以绘制出整个系统的核心流程：</p>
-<p><img src="assets/85f8d4c0-c32a-11e8-a79d-27388006ab48" alt="enter image description here" /></p>
+<p><img src="assets/85f8d4c0-c32a-11e8-a79d-27388006ab48" alt="png" /></p>
 <p>作为核心流程的子流程，项目管理流程与招聘流程是更低一级的业务流程。在先启阶段，如果为了获得更加准确的主故事列表，仍然有必要进一步细化这些子流程。从敏捷开发的角度讲，我们也可以将这些流程的细化放到对应迭代的需求分析活动中，以便于尽快完成先启阶段，进入到项目的正式迭代阶段。毕竟在确定了产品的待办项（史诗级故事与主故事）之后，已经足以帮助团队确定发布与迭代计划了。</p>
 </div>
                     </div>