提炼问题域

参与人员 - 业务（领域专家）和技术（开发人员）进行协作

• 业务相关人员更关注某个功能的输入和输出，但是领域专家可以从政策，工作流程到领域棘手问题和特性都有深刻理解或者很强领悟的人，可以帮助开发团队制作出满足业务相关人员需要的有用模型。
• 通过显式的定义一些业务隐藏概念，可以让领域专家更好的证明他对领域的理解是否正确。让开发人员获得领域知识。
• 领域专家和开发人员要频繁互动，以便让领域专家能够帮助分析，解决问题。

方法 - 知识提炼

• 复杂问题域包含大量信息，有些可能与要解决的问题没有关系。因此我们需要对复杂问题域中的信息进行提炼出相关信息。这个提炼的技术叫做知识提炼。
• 模型是使用富含领域专有术语的通用语言进行描述的。这样才能使得业务和开发可以对于软件进行有效沟通。
• 领域知识很重要。不论开发/业务在进行沟通的时候，需要有同样的领域知识才行，这样开发和业务 才能够通过简单的术语进行沟通，开发才能够设计出满足业务用例的模型。因此，需要更关注业务问题，而不是仅仅关注技术。
• 业务员分析师可以帮助业务和开发进行有效沟通，但是，不能将业务和开发隔离开来，只通过业务分析师进行沟通
• 持续的过程 - 随着外部因素（新增需求，问题域的专业术语）和内部因素（更简单的建立模型）的变化，模型也需要进行演化，因此，需要持续不断的进行知识提炼

如何做 - 知识提炼的模式

• 首先，专注在最有意思的对话上。一次讨论需求列表多条，首先讨论使得业务发生改变，系统取得关键成功的核心部分需求。
• 其次，通过用例映射进行描绘，理解用户想用系统做什么。抓住真实情况的过程图，理解实际的工作流程。
• 然后，提问：

1. 系统需求来自何处？
2. 系统如何为业务提供价值？
3. 如果不构建这个系统会发生什么情况？

• 然后，画UML图
• 然后，细化领域中的概念 - CRC卡（类名 - 概念名，类的职责，相关联的类）
  Tips：
• 概念不清楚之前，不要命名，可以用一些难以理解的词命名，比如银河系，太阳，量子等。
• 用BDD有助于UL（统一语言）的形成
• 可以快速编码，但必须在解决制定问题的特定上下文中进建立代码模型
• 一些边缘情况，业务价值不高，可以不用建模，比如，5年才可能需要出一次的报表。

怎么做 - 查看现有模型

• 找到用户真正的需求。
• 事件风暴 - 能够揭示问题的子域和核心域。
• 影响地图
• 理解现有的业务模型 - 《Business Model》

1. 客户细分 - 企业目标客户的不同类型。
2. 价值提供 - 一家企业为客户提供的产品和服务。
3. 渠道 - 企业将其此产品和服务交付给客户的方式。
4. 客户关系 - 企业域每个客户细分市场的关系类型。
5. 营收来源 - 企业盈利的不同方式。
6. 核心资源 - 企业最重要的资产。
7. 核心活动 - 维持企业运转的根本活动
8. 核心合作伙伴 - 企业最重要的合作伙伴名单。
9. 成本构建 - 企业要花费的成本。

• 刻意发现 - 要花时间去学习你不了解的问题域。由领域专家和业务相关人员来主导
• 模型探讨漩涡- 当在创建模型期间遇到问题时，使用

1. 场景探讨
2. 建模
3. 考研模型
4. 收集于记录
5. 代码探究