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 不追求处处完美
- 专注于清晰边界而非完美模型
- 核心领域也是不断演化的
小结
- 对大问题进行分解、提炼以便找出核心、支撑和通用域
- 提炼有助于降低问题空间的复杂性
- 更加专注于核心领域
网友评论