DDD专题系列(二)---战略设计(识别问题域, 提炼领域知识)

二、战略设计(识别问题域, 提炼领域知识)

​ 首先摆一张大部分人非常眼熟的图片, 从这张图种大概能看到整个DDD战略设计部分的清晰脉络，之后战略设计部分我也将按照这个流程去讲。从一本书上得来的一种思路，我这里模拟出一家公司出来，然后逐渐把DDD落地。

​ 在准备阶段我想先介绍一下这家公司的背景，这家公司想做传统房地产转型，那么我们所在的领域就是房地产领域。我们在转型的同时就是使用互联网方式解决房地产领域的相关问题。其中我们所需要最关键的角色就是领域专家，这里对于领域专家的介绍非常泛，这是一个没有明确规定的岗位，只要对于所在领域有丰富的经验和技能，他们好似一个桥梁，一座让互联网基因融入到各个行业的桥梁，这一个角色对于整个项目成败起着直接影响。

​ 有了这样一群丰富经验的领域专家和优秀的开发者，产品经理，可以开始干活了。这也就引出了我们标题中所提出的识别问题域, 提炼领域知识，来分析一下这两个短语，形式均为 动词 + 名词。

识别 问题域:

1. 人才有问题，我们必须找到对应岗位的人去倾听他们的问题

2. 既然提到识别，肯定是问题有真有假，才需要识别

3. 域代表范围，每一个特定范围内的问题肯定不一样，我们必须要找准特定范围

   这里比较好用的方法是讲故事，我们按照特定角色或是一类相关的角色做成一个册子，然后集册中装着一个个的故事模板

As a (作为) (角色)

I would like (我希望整个软件) <活动>

So that(以便于) <业务价值>

我们第一步所要做的就是收集对应人的故事集册，这里我例举一个:

(1) As a 业务主管

(2) I would like 这个软件(系统或是应用) 有关联线上订单的功能(这个功能是目前房产领域中的一个功能)
    
(3) So that 用户能够更快地走完购房流程

​ 从上述例子中看出，整个故事或者叫模板是非常单薄,简洁的，但是真正落实的时候，却远远没有想象的那么简单。我们需要练就一双“火眼金睛”，这里我来描述这样一种情况:

张三的用户故事: 
(1)作为一名驻场文员
    
(2)我希望结算系统这个软件有导出功能
    
(3)以便于我能够更快地完成我的本职工作
(他操作Excel更顺手)

李四的用户故事:
(1)作为一名主管
    
(2)我希望结算系统这个软件有关联线上订单的功能
    
(3)以便于用户能够更快地走完购房流程

​ 这里有两个不同的人(角色)，他们都讲出了属于自己的用户故事。其中都提出了一个"更快"的词，但是仔细观察会发现，这些故事中有一真一假。众所周知，每一个系统或是软件都有一个核心目的(用途)，我想用我在学校里面做的一个项目为例，让大家理解。自来水厂下有许多抄表员，抄表员去每一户人家抄表，我们所开发的系统名字叫做: 抄表云管理平台，这个系统能够给抄表员分配任务，记录抄表员抄表时的轨迹，还能通过拍照进行表盘读数，异常水表的管理和审核。可是在项目上线的时候，负责人验收通过了，但是抄表员们却不是很开心，因为原来的抄表员每个月抄表非常自由，反正我什么时候抄都可以，上面也不知道。可是这个软件应用上线后，他们每个月的工作量，什么时候抄的表，都需要上报和审核，他们觉得这反而减慢了他们的速度。 负责人解释说: 这个软件(系统)的根本作用就是为了加强对于抄表员的管理和规范，至于他们自己所说的速度问题，根本不是这个系统所要解决的问题(其实并没有影响整体效率, 因为抄表总共一个月就一次，这里可以得出 规范 >> 效率)。最终我明白了，这个软件的核心目的就是加强抄表员的管理和规范，如果其他的附加目的对核心目的产生了冲突，那必然这个需求是 “伪”的。

​ 让我们再来看上面张三和李四的例子，我们的系统的核心目的是***加快整体的购房的流程***，但是其中一个人站在自己的角度提出要加快自己手头上的工作的速度，至于是否真的能够通过提高他个人(或者部分人)的工作速度来加快整体购房流程，这里或许我们应该存疑?需要更近一步对于整体流程有更深入的了解才能得出结论。相反，主管提出的用户故事则站在全局的角度去看的，他得出的结论相对来说更准确些。

​ 这里总结一下，对于不同用户和角色提出的用户故事，我们总是要确立一个唯一的核心方针。以它为依据，分析谁才是真需求，谁是伪需求? 谁能够最大程度发挥更大的业务价值?对于核心方针起到保留的需求我们需要保留，和核心目的冲突的附加目的，我们要适当保留和去除。最后经过严格的筛选我们对于不同的角色/角色，拥有不同的故事，这些集册保存形式不重要，只要分类明确，查看清晰，它们将贯穿我们整个开发，测试，验收过程。他们能够在非常多的地方发挥巨大作用！

• 总结一下

  ​ 至此，我们终于讲完了如何识别问题域, 其实这些和产品有关，但是在DDD中，对于开发人员的理解业务，整理业务的能力也提出了较高的要求。如何正确识别真正的业务价值是这里的关键所在，识别并且屏蔽噪声，及时纠正偏差。下一篇文章我将更具体展现这些故事在实际场景中的作用。