2、提炼问题域

2.1 知识提炼与协作

知识提炼的过程开始于一个系统的行为，开发人员和专家要一起探讨应用程序的使用场景。

image.png

• 通过通用语言达成共识
• 领域知识是关键，重要性高于技术知识
• 业务分析员是重要的角色
• 知识提炼是一个持续过程
• 随着迭代的演进，对问题域的理解会提升

2.2 与领域专家一起获得领域见解

• 业务人员提出想要什么，领域专家可以帮你制作满足业务的模型
• 领域专家能够对业务领域的政策和工作流程、特性都有深刻的理解
• 在协作中突破原有的理解

2.3 提炼知识的模式

• 专注在最有意思的话题上
• 从用例开始，理解用户与系统之间的交互。通过复述的方式验证你理解的问题是否与专家一致。最终理解真实的过程图、工作流程。
• 提出有力问题，理解构建的产品的重要性以及理解背后的目的，示例问题：
  （1）需求来自何处？
  （2）这个系统如何为业务提供价值？
  （3）如果不构建这个系统会发生什么情况？
• 草图
  （1）绘制草图时注意保持相同的抽象层次上
  （2）可使用少量的UML语言描述，不必像Viso和Rational Rose那样精心设计
• CRC卡，专注于思考问题域中的概念：类名、职责、相关类
• 延迟对概念命名，当心太多含义的术语
• 行为驱动开发
• 快速开发原型，寻找遗漏
• 查看纸面系统，通过纸面解决方案了解过程和工作流

2.4 查看现有模型

寻求现有过程图、工作流程图，创建术语和知识库在团队中共享知识

• 理解意图
  （1）理解了客户的真正意图，才能提供更好的解决方案
  （2）理解隐含的愿景
• 事件风暴
• 影响地图
• 理解业务模型
• 刻意发现
• 模型探讨漩涡
  （1）场景探讨：领域专家对重要的场景进行解释，使团队成员能够理解。小组成员再对长江进行绘图。
  （2）建模：团队成员对场景建模并评估是否有效解决领域专家的场景问题。
  （3）考验模型：通过更多场景对模型进行考验
  （4）收集和记录：记录模型如何解决问题域中的关键问题
  （5）代码探究：技术团队通过代码证明能够实现

小结：

• 让领域专家参与到系统最重要的部分

3、专注核心领域

并非一个问题的所有部分都是同等重要的

3.1 为何要分解一个问题域

• 通过分解大的问题域，可以更有效的为不同区域分配资源
• 单模型如果要满足所有的领域需求，模型可能过于复杂
• 小模型更容易管理，可以绑定到一个特定的上下文

3.2 如何捕获问题的实质

值得考虑的问题：

为什么编写软件而不是选择一款现成的商业产品？
该应用对业务能起决定作用吗？
为何该应用是自建而不是外包？
该软件的一部分能为业务提供竞争优势吗？

• 超越需求
  （1）寻找需求背后的动机
  （2）理解你隐含的愿景，了解业务尝试达到的目标，提供真正的业务价值
• 捕获领域愿景
  （1）为何公司要构建软件？
  （2）在项目初期构建愿景，用以阐明什么内容对软件的成功是主要的、业务目标是什么、价值在哪里。

3.3 如何专注核心问题

核心领域：提供的独特的与竞争对手区别开来的区域，以及赋予其在市场中竞争优势的内容

• 提炼问题域：提炼核心域在哪里
• 核心领域：核心领域需要最好的开发人员；核心域随着业务的发展也会发生变化
• 将核心领域当作一款产品：
• 通用域：包含电子邮件、报表、账户管理
• 支撑域

3.4 不追求处处完美

• 专注于清晰边界而非完美模型
• 核心领域也是不断演化的

小结

• 对大问题进行分解、提炼以便找出核心、支撑和通用域
• 提炼有助于降低问题空间的复杂性
• 更加专注于核心领域