提煉問題域

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

• 客戶細分
• 價值提供
• 渠道
• 客戶關係
• 營收來源
• 核心資源
• 核心活動
• 核心合做夥伴
• 成本結構

2.4.5 刻意發現

2.4.6 模型探討漩渦