提炼问题域
参与人员 - 业务（领域专家）和技术（开发人员）进行协作
-
业务相关人员更关注某个功能的输入和输出，但是领域专家可以从政策，工作流程到领域棘手问题和特性都有深刻理解或者很强领悟的人，可以帮助开发团队制作出满足业务相关人员需要的有用模型。
- 通过显式的定义一些业务隐藏概念，可以让领域专家更好的证明他对领域的理解是否正确。让开发人员获得领域知识。
- 领域专家和开发人员要频繁互动，以便让领域专家能够帮助分析，解决问题。
方法 - 知识提炼
- 复杂问题域包含大量信息，有些可能与要解决的问题没有关系。因此我们需要对复杂问题域中的信息进行提炼出相关信息。这个提炼的技术叫做知识提炼。
- 模型是使用富含领域专有术语的通用语言进行描述的。这样才能使得业务和开发可以对于软件进行有效沟通。
- 领域知识很重要。不论开发/业务在进行沟通的时候，需要有同样的领域知识才行，这样开发和业务 才能够通过简单的术语进行沟通，开发才能够设计出满足业务用例的模型。因此，需要更关注业务问题，而不是仅仅关注技术。
- 业务员分析师可以帮助业务和开发进行有效沟通，但是，不能将业务和开发隔离开来，只通过业务分析师进行沟通
- 持续的过程 - 随着外部因素（新增需求，问题域的专业术语）和内部因素（更简单的建立模型）的变化，模型也需要进行演化，因此，需要持续不断的进行知识提炼
如何做 - 知识提炼的模式
- 首先，专注在最有意思的对话上。一次讨论需求列表多条，首先讨论使得业务发生改变，系统取得关键成功的核心部分需求。
- 其次，通过用例映射进行描绘，理解用户想用系统做什么。抓住真实情况的过程图，理解实际的工作流程。
- 然后，提问：
- 系统需求来自何处？
- 系统如何为业务提供价值？
- 如果不构建这个系统会发生什么情况？
- 然后，画UML图
- 然后，细化领域中的概念 - CRC卡（类名 - 概念名，类的职责，相关联的类）
Tips： - 概念不清楚之前，不要命名，可以用一些难以理解的词命名，比如银河系，太阳，量子等。
- 用BDD有助于UL（统一语言）的形成
- 可以快速编码，但必须在解决制定问题的特定上下文中进建立代码模型
- 一些边缘情况，业务价值不高，可以不用建模，比如，5年才可能需要出一次的报表。
怎么做 - 查看现有模型
- 找到用户真正的需求。
- 事件风暴 - 能够揭示问题的子域和核心域。
-
影响地图
-
理解现有的业务模型 - 《Business Model》
- 客户细分 - 企业目标客户的不同类型。
- 价值提供 - 一家企业为客户提供的产品和服务。
- 渠道 - 企业将其此产品和服务交付给客户的方式。
- 客户关系 - 企业域每个客户细分市场的关系类型。
- 营收来源 - 企业盈利的不同方式。
- 核心资源 - 企业最重要的资产。
- 核心活动 - 维持企业运转的根本活动
- 核心合作伙伴 - 企业最重要的合作伙伴名单。
- 成本构建 - 企业要花费的成本。
- 刻意发现 - 要花时间去学习你不了解的问题域。由领域专家和业务相关人员来主导
- 模型探讨漩涡- 当在创建模型期间遇到问题时，使用
- 场景探讨
- 建模
- 考研模型
- 收集于记录
- 代码探究
