第2章 提炼问题域

第2章 提炼问题域

理解一个复杂的问题域以便创建简单且有用的模型需要深入详尽的知识以及深刻的见解，这些只能通过与从内到外的理解该领域的人协作得到。

提炼领域知识的方法。

提取一个应用程序行为方面的重要信息的方法，以便探讨问题域内部深刻见解的技术。

 

1. 知识提炼与协作

知识提炼是为基数团队基于一组需求为问题域设计解决方案时弥补所欠缺的知识的关键技术。

与业务用户，业务相关人员和主题专家等合作，进行头脑风暴，基于业务用例不断提炼知识，并构建模型。

 

1. 1. 通过通用语言达成共识

只是提炼的输出以及共识的构件就是常见的通用语言UL，该UL不仅在领域模型中，还贯穿至代码实现，使用用作类名称，属性和方法名称的相同的术语和概念。

 

1. 1. 领域知识的重要性

领域知识是关键，其重要性甚至要远甚于技术知识。

要想快速响应需求，那么领域知识的深刻理解和模型建立不可缺少。

 

1. 1. 业务分析员的角色
   2. 一个持续过程

一个好的模型要能够灵活支持变更，一个程序的模型会保佑丰富且传神的概念以及问题域的专业术语，并且能同时为业务和技术团队所理解。

模型永远不会尽善尽美，它只是对于当前问题可用而已。

开发团队，业务相关人员以及主题专家的协作不仅仅在项目开始阶段，每一次迭代升级都要协作且贯穿于项目的生命周期所有阶段。

 

1. 与领域专家一起获得领域见解

领域专家很难找，这类人是指那些从业务领域的政策和工作流程到其棘手处和特性都具有深刻理解的人。

大部分都是寻找你当前工作领域具有很强的领悟和理解的产品所有者，用户或者其他任何人，而不是他们的头衔了。

 

1. 1. 领域专家与业务相关人员的对比

问题空间会给出一组需求，输入和预期输出，这通常是你的业务相关人员提供的。

解空间包含了一个能够满足需求需要的模型，这正是领域专家能够提供帮助的地方。

 

1. 1. 对于业务的更深刻理解

 

 

1. 1. 与你的领域专家互动

随时，随地尽可能多的与领域专家沟通。

 

1. 有效提炼知识的模式

让整个知识的提炼过程有趣，甚至以游戏的方式来获取知识。

 

1. 1. 专注在最有意思的对话上

与业务人员最有意思的对话将揭示你应该在何处花费最大精力来达成共识和创建通用语言。

跟业务人员沟通，询问哪些是业务的核心部分。

        

1	询问领域专家当前系统的那些部分难以使用
2	哪些手动处理过程阻止了他们进行更具创造性，有附加值的工作
3	哪些修改将提高收益，提高运营效率并最大限度地节约资金
4	追踪资金去向并找出花费业务资金的区域或者减少这些支出提升收益通常是一个好的做法。

 

1. 1. 从用例开始

记住：抓住真实情况的过程图，理解实际的工作流程，在你真正理解并重视 问题之前不要试图过快地到解决方案。

 

1. 1. 提出有力的问题

1	这个系统的需求来自何处？
2	这个系统会如何为业务提升价值？
3	如果不构建这个系统会发生什么情况？
4	这个系统良好情况看起来是什么样子？
5	这个产品的成功标准是什么？
6	什么才是值得去努力做的？
7	该业务试图达成什么目标？

 

提出有力问题：http://goodenoughsoftware.net/2012/02/29/power-questions

 

1. 1. 草图

绘制草图时，一个基本原则可以帮助你创建高效的图标：将你的图标保持在一个稳定的细节水平。如果是套路高层次的问题，比如领域交互，就不要体现太多的细节，比如类，模块等。

创建多个图标以分别对应每一种不同的细节水平，不同问题切面会更好。

先画草图，再将稳定模型使用UML等visio制作。

 

1. 1. CRC卡

 

1. 1. 延迟对模型中概念的命名

过早命名会导致在你未深刻理解领域知识前的错误命名，最初选定的这个词所带来的联想以及它会限定你的思维方式。

直到你理解这个问题的责任职责，行为以及数据。

 

1. 1. 行为驱动开发

行为驱动开发（Behavior-Driven Development，BDD）是一种软件开发过程，它基于测试驱动开发（Test-Driven Development，TDD），其专注于获取系统的行为，然后由外而内地驱动设计。BDD会使用具体的领域场景以描述系统行为。

 

1. 1. 快速成型

知识提炼环节期间支持快速成型。业务更喜欢可见的UI，他们可以与其交互并清晰地演示出工作流程。

快速编码有助于创建你的有力问题并帮助找到遗漏的用例。

记着你的代码是会被丢弃的代码，不要止步于第一个模型，第一个好的想法。

 

1. 1. 查看基于纸面的系统

有一些过程和工作流程可能无法从精心设计的模型中获得处理边缘情况的益处。

极少数边缘情况的场景继续由人工处理可能更好解决。

对此情况进行建模可能会浪费大量的精力，但只能产生很少的业务价值。

 

1. 查看现有模型

查询所属行业的模型，比如金融机构。

Martin Fowler的《analysis patterns: reusable object models martin fowler》一书中，已经列举了许多模型。

   

 

1. 1. 理解意图

要理解业务的真实需求，跳出这个软件的约束。

软件设计要有“主导”意识，而非盲从业务需求人员，且他们一般无法准确获知功能开发和价值比。

业务人员 可能并不能清晰地描写有效特性或者有效地表述目标。

你必须共享和理解隐含的愿景，并且认识到业务试图达成什么，这样你才能创造真正的业务价值。

 

1. 1. 事件风暴

 

 

1. 1. 影像地图

用于更好理解业务相关人员意图的一项新技术是影响地图。

先确定业务的真实目的？

1	提高销售量？
2	提高市场份额？
	希望进入一个新的市场？
	希望提高忠诚度以便得到更多具有高生命周期价值的忠实顾客？

 

以下为举例，提高 25% 的自行车的销量。

 

1. 1. 理解业务模型

业务模型包含大量有用的领域信息并且重点强调业务的根本目标。

1. 1. 刻意发现

Dan宣称，“无知是生产能力的单一最大阻碍”。因此更大量的领域知识将会改善你的建模工作。

由业务人员协助，让团队专注在重要的区域上，而不是简单地提炼整个问题域。

这将使得团队能够识别出领域知识所欠缺的部分，并以一种快速的方式弥补所欠缺的知识。

 

1. 1. 模型探讨旋涡

 

1. 要点汇总