2.1 知识提炼与协作
知识提炼是从问题域中提炼出相关信息的技术，其目的是构建能够满足业务用例需求的有用模型。
知识提炼是为技术团队在基于一组需求为问题域设计解决方案时弥补所欠缺的知识的关键技术。
知识提炼--对问题深刻理解的人--大家的共同协作。
知识收集过程会出现在与业务专家探讨示例时的白板上，且通常会同时展开头脑风暴。
问题域 == 业务用例 ==有用的模型 == 知识提炼。具体操作一波。
2.1.1 通过通用语言达成共识
通用语言（UL）显示制作，并在描述领域模型和问题域使用，该语言还应用于模型的代码实现，使用用作类名称，属性和方法名称的相同的术语和概念。
2.1.2 领域知识的重要性
领域知识 == 业务知识 技术知识
从业务到技术的翻译是开发人员需要具备的。
2.1.3 业务分析员的角色
不要将开发团队和最理解该部分业务的人之间的沟通完全屏蔽。
2.1.4 一个持续过程
模型驱动设计和领域模型的演化是一个持续过程。知识提炼在整个应用程序构建的生命周期中应该在业务参与的情况下被持续关注。 认识到随着系统的每一次迭代，模型都会有所演化，===模型永远不会尽善尽美，它只是对于当前问题可用而以。
2.2 与领域专家一起获得领域见解
2.2.1 领域专家和业务相关人员的对比
问题空间会给出一组需求，输入和预期输出 ===业务相关人员提供的。 解空间包含一个能满足需求需要的模型 ===领域专家的地盘。
问题空间 & 解空间
2.2.2 对于业务的更深刻理解
与领域专家一起工作并不是仅仅让开发团队能够获得他们正在处理的问题域的知识，还有助于领域专家证明其对该领域的理解。可能业务隐含的概念是由开发团队和领域专家显示定义的，这将使得业务本身的沟通交流得到改善。
2.2.3 与你的领域专家互动
利用与你的领域专家在一起的时间，展示对于领域知识的渴望。
2.3 有效提炼知识的模式
大家都很忙，要有趣。
2.3.1 专注在最有意思的对话上
首先处理问题域中让业务人员需要深夜加班的部分--那些将使得业务发生改变且对于应用程序取得成功是核心的部分。
最有意思的对话将揭示出你应该在何处花费最大的精力来达成共识和创建通用语言。
2.3.2 从用例开始
用例会列出达成目标所需的步骤，其中包括用户和系统之间的交互。
2.3.3 提出有力的问题
- 需求来自何处
- 系统的价值在哪里
- 如果不做会发生什么。
2.3.4 草图
- 图表加快理解。
- 快速绘制保持交流的快速和迭代的快速。
- 图表的层次概念，不要用层级的混淆。
2.3.5 CRC卡
CRC卡被划分三个部分且包含以下信息
- 类名称，它表示领域中的一个概念。
- 类的职责。
- 与满足其目的的相关且所需的类。
2.3.6 延迟对模型中概念的命名
术语要准确，无法表达时，可以暂缓命名。
2.3.7 行为驱动开发
行为驱动开发（BDD） 是一种软件开发过程，基于测试驱动开发（TDD），其专注于获取系统的行为，然后由外而内地驱动设计。
BDD 关注的是软件行为、系统应该产生怎样的行为。 DDD 关注的是用于实现行为的软件核心的领域模型，细微但是重要的区别。
2.3.8 快速成型
2.3.9 查看基于纸面的系统
2.4 查看现有模型
2.4.1 理解意图
理解用户，用户的需求是基于当前系统的想象，而不是其最终的目的。必须共享和理解隐含的愿景，并且认识到业务试图达成什么，这样才能创造真正的业务价值。
2.4.2 事件风暴
事件风暴是一种研讨会活动，它旨在为业务和开发团队以一种有趣动人的方式快速建立对问题域的理解。
对问题域的探讨过程。
2.4.3 影响地图
理解业务试图作出的影响，更有效的帮助他们达成目标。 要求提出更好的问题，明白要达成的目的。
2.4.4 理解业务模型
Busines Model Generation
- 客户细分
- 价值提供
- 渠道
- 客户关系
- 营收来源
- 核心资源
- 核心活动
- 核心合作伙伴
- 成本结构