提煉問題域
參與人員 - 業(yè)務（領域專家）和技術（開發(fā)人員）進行協(xié)作
-
業(yè)務相關人員更關注某個功能的輸入和輸出，但是領域專家可以從政策，工作流程到領域棘手問題和特性都有深刻理解或者很強領悟的人，可以幫助開發(fā)團隊制作出滿足業(yè)務相關人員需要的有用模型。
- 通過顯式的定義一些業(yè)務隱藏概念，可以讓領域專家更好的證明他對領域的理解是否正確。讓開發(fā)人員獲得領域知識。
- 領域專家和開發(fā)人員要頻繁互動，以便讓領域專家能夠幫助分析，解決問題。
方法 - 知識提煉
- 復雜問題域包含大量信息，有些可能與要解決的問題沒有關系。因此我們需要對復雜問題域中的信息進行提煉出相關信息。這個提煉的技術叫做知識提煉。
- 模型是使用富含領域專有術語的通用語言進行描述的。這樣才能使得業(yè)務和開發(fā)可以對于軟件進行有效溝通。
- 領域知識很重要。不論開發(fā)/業(yè)務在進行溝通的時候，需要有同樣的領域知識才行，這樣開發(fā)和業(yè)務 才能夠通過簡單的術語進行溝通，開發(fā)才能夠設計出滿足業(yè)務用例的模型。因此，需要更關注業(yè)務問題，而不是僅僅關注技術。
- 業(yè)務員分析師可以幫助業(yè)務和開發(fā)進行有效溝通，但是，不能將業(yè)務和開發(fā)隔離開來，只通過業(yè)務分析師進行溝通
- 持續(xù)的過程 - 隨著外部因素（新增需求，問題域的專業(yè)術語）和內部因素（更簡單的建立模型）的變化，模型也需要進行演化，因此，需要持續(xù)不斷的進行知識提煉
如何做 - 知識提煉的模式
- 首先，專注在最有意思的對話上。一次討論需求列表多條，首先討論使得業(yè)務發(fā)生改變，系統(tǒng)取得關鍵成功的核心部分需求。
- 其次，通過用例映射進行描繪，理解用戶想用系統(tǒng)做什么。抓住真實情況的過程圖，理解實際的工作流程。
- 然后，提問：
- 系統(tǒng)需求來自何處？
- 系統(tǒng)如何為業(yè)務提供價值？
- 如果不構建這個系統(tǒng)會發(fā)生什么情況？
- 然后，畫UML圖
- 然后，細化領域中的概念 - CRC卡（類名 - 概念名，類的職責，相關聯(lián)的類）
Tips： - 概念不清楚之前，不要命名，可以用一些難以理解的詞命名，比如銀河系，太陽，量子等。
- 用BDD有助于UL（統(tǒng)一語言）的形成
- 可以快速編碼，但必須在解決制定問題的特定上下文中進建立代碼模型
- 一些邊緣情況，業(yè)務價值不高，可以不用建模，比如，5年才可能需要出一次的報表。
怎么做 - 查看現(xiàn)有模型
- 找到用戶真正的需求。
- 事件風暴 - 能夠揭示問題的子域和核心域。
-
影響地圖
-
理解現(xiàn)有的業(yè)務模型 - 《Business Model》
- 客戶細分 - 企業(yè)目標客戶的不同類型。
- 價值提供 - 一家企業(yè)為客戶提供的產品和服務。
- 渠道 - 企業(yè)將其此產品和服務交付給客戶的方式。
- 客戶關系 - 企業(yè)域每個客戶細分市場的關系類型。
- 營收來源 - 企業(yè)盈利的不同方式。
- 核心資源 - 企業(yè)最重要的資產。
- 核心活動 - 維持企業(yè)運轉的根本活動
- 核心合作伙伴 - 企業(yè)最重要的合作伙伴名單。
- 成本構建 - 企業(yè)要花費的成本。
- 刻意發(fā)現(xiàn) - 要花時間去學習你不了解的問題域。由領域專家和業(yè)務相關人員來主導
- 模型探討漩渦- 當在創(chuàng)建模型期間遇到問題時，使用
- 場景探討
- 建模
- 考研模型
- 收集于記錄
- 代碼探究
