DDD
關於領域專家
領域專家是主題內容專家，他們了解我們要用程式碼建模和實作所有複雜業務，換句話說，領域專家是軟體業務領域知識權威。
領域專家的專業知識其實有不同範圍，有可能會是分析師、業務利害關係人…在實務上最常見的是提出需求的人與End User。
最常見就是產品經理、業務分析師、資深員工、或其他在業務領域中具備豐富經驗的人，這邊資深員工有講的是在一家公司服務了一定年紀，對公司的業務和產品與系統運作非常了解的人。
在GPT當中DDD的領域專家有提出四項原則，我認為還蠻重要的
主要職責
知識提供者：領域專家負責向開發團隊提供業務規則、流程和邏輯方面的知識。他們能夠解釋業務需求和背景，確保開發團隊理解業務的運作方式。
決策參與者：在 DDD 的過程中，領域專家參與決策，幫助確定哪些功能是系統中的核心，哪些功能是輔助性的。他們有助於確保系統的設計符合業務需求。
模型驗證者：領域專家與開發人員一起檢查領域模型，確保它們正確反映了業務規則和流程。他們協助調整模型以更好地符合實際業務需求。
持續參與：領域專家並不僅僅在項目初期參與，他們通常在整個開發過程中都保持參與，以確保開發團隊始終朝著正確的方向前進。
最後領域專家的參與，對於落地DDD 的成功至關重要，因為領域專家提供的業務知識和見解可以幫助開發團隊避免誤解需求，並創建更準確和有效的系統，也就是說必須要和領域專家能夠進行有效溝通。
知識發現與心智模型
在開發人員角度至少要具備掌握領域知識的基本知識，領域專家掌握了這些知識，建造出來的軟體是為了模仿領域專家思考的問題方式，也就是所謂心智模型。
來看看GPT所說的心智模型部分，何謂心智模型
心智模型（Mental Model）是人們對世界的一種內在表徵，它幫助個體理解和預測外部環境中的各種情況和行為。這些模型是一種簡化和抽象化的思維框架，人們通過它來組織、解釋和應對他們所面對的各種問題和情境。
心智模型的特點
個人化：心智模型基於個人的經驗、知識和信念，因此每個人對同一事物的心智模型可能會不同。
簡化複雜性：心智模型幫助個體簡化外部世界的複雜性，使他們能夠快速做出決策和預測結果。
動態性：心智模型是動態的，可以隨著經驗和知識的增加而改變或演化。當人們獲得新的信息或經歷新的情況時，他們會調整其心智模型以更好地反映現實。
有限性：由於心智模型是一種簡化的表徵，因此它們往往並不完全準確，可能會忽略一些細節或導致誤解。
心智模型的重要性
心智模型在許多方面影響著我們的行為和決策：
- 決策制定：心智模型是人們做出決策的基礎。它們幫助人們評估選項、預測結果，並選擇最佳行動方案。
- 問題解決：在面對問題時，人們使用心智模型來理解問題的結構，並設計解決方案。
- 學習與適應：心智模型影響學習過程。隨著個體獲得更多知識，他們會更新或重建心智模型，以適應新的情況。
筆者看待心智模型是心智模型有點類似我們常常在腦海裏面的連貫操作步驟，什麼時機點，你知道做什麼，這個有點抽象對吧?
白話一點就是指南，也就是大腦中的指南針。
舉個例子：筆者最常見的實務上投資理財應用。
筆者的投資心智模型
- 投資的原則
- 資產配置
- 工具(如股票或ETF或債券ETF…等金融資產)
對每一項金融產品有基本認識也知道優缺點，集合起來的一聯串的策略操作
為何心智模型會那麼抽象和那麼難
原因就在於哲學，我們來看看上面的探討的投資，因為這一聯串操作會變成是一個投資哲學。
Alberto Brandolini：軟體開發是一個學習過程，運作程式碼只是一個附加結果。
關於溝通
傳統開發流程會是：領域專家→SA→整理需求→開發人員→實做程式碼→交付給使用者。
這種軟體開發流程就是傳話遊戲。
傳話遊戲很常被扭曲，因為實做的過程中領域知識常常被誤解或是錯誤訊息，來實做出錯誤的解決方案。
關於統一語言
領域驅動設一種更好方式讓軟體工程師獲取知識，透過統一語言。
DDD當中的統一語言，將所專案利害關係人─軟體工程師、產品負責人、領域專家、UI/UX在描述業務領域用統一語言。
領域專家要能熟悉和駕馭使用統一語言，這種語言代表業務和領域專家的心智模型。
心智模型特性
模型包括以下幾個關鍵元素：
- 共享理解
- 實體面對面交流
- 具體化或視覺化-(註：為的是將隱形問題浮現出來)
- 共創與反饋循環
- 模糊邊界消除
- 貫穿全局
共享理解：
統一語言的核心是建立一個所有參與者都能理解並使用的語言。這個語言源自於業務領域，且不僅僅是業務術語，還包括了業務邏輯和規則。目的是確保每個人在討論和設計系統時，都在使用相同的語言來描述相同的概念。
實體面對面交流：
統一語言的心智模型強調實體面對面交流、持續的交流。這意味著開發人員、業務專家和其他利益相關者需要不斷地溝通和協作，以確保語言的演變隨著業務需求的變化而更新。
具體化或視覺化：
在這個模型中，統一語言應該視覺化為模型、程式和文件。例如，如果業務專家在討論中提到「客戶」這個概念，那麼這個概念應該在程式中作為一個具體的類別或物件來實作。透過這樣方式就不僅僅是技術實作也是業務邏輯的直接表達。
共創與反饋循環：
統一語言需要在反覆的共創過程中逐漸完善。業務專家提出的概念會反映在模型和程式中，而開發人員的實現則反過來影響業務專家對系統的理解。這樣形成一個持續的反饋循環，促進統一語言的進一步成熟。
模糊邊界的消除：
心智模型強調通過使用統一語言來消除模糊和誤解。團隊應該主動識別並解決任何不明確的術語或概念，確保所有參與者對系統的理解是一致且清晰的。
貫穿全局：
統一語言的心智模型還強調其應該貫穿於整個軟體開發生命週期中，從需求分析到設計、實現、測試再到最終部署和維護，統一語言都應該作為溝通的基礎工具，並且不斷進化。
統一語言注意地方
同義詞的不能互換使用，例如：客戶-Customer和使用者-User，這兩者不能互用。
Customer和User是在業務邏輯上有不同的焦點和角色，如果使用者誤認為客戶，就會導致忽略一些重要功能相關需求，客戶才是主要我們關注的商業客戶關係管理部分，用來管理客戶帶來收入的實體物件，也是為公司帶來收入的角色，使用者可能是操作系統系統，但是使用者有可能拆分為訪客或是管理員或者是操作系統的帳戶...等。
例如：訂單Order-與合約-Contact，這兩者也是不能互用。
結論：統一語言當中若遇到同義詞也有包含不同的業務含義與邏輯，在設計的時候必須留意避免邏輯錯誤和誤解。
註記：統一語言是持續的過程，隨專案進行發展，將有更多領域知識發現，反映洞察統一語言相當重要。
探討模型
筆者在看模型這件事情，首先我們來看什麼是模型，這時候要引用Rebecca Wirfs-Brock
模型是對事物或現象的簡化表示，它對有意強調某些面向而忽略其他面向，是心中有明確用途的抽象化。
目的：幫助明白真實世界系統中人們的構想。
模型例子：地圖，不同類型地圖顯示世界的不同模型-道路、時區、地形、地形鐵路…
地圖不能知道所有細節，但實際地圖上包含足夠資料和支援特地的目的：它要解決的問題。
來看看某系統ERD的模型，可以思考看看….
上述這個模型是有效?
ERD模型光是讓人看懂就得花很多時間了…在實務上不是每個人都懂ERD，這個模型是不是真的是有效模型?
關於領域驅動設計中的模型
- 有效建模
- 業務建模：該模型是對照領域專家的思維過程，有關業務要如何實作和發揮功用，模型反映出業務實體、行為、因果關係、故動規則。
- 持續努力：和領域專家互動才能發現不準確與錯誤的假設，整個業務上的理解缺陷。
- 工具：搭配工具和技術改善捕捉和管理統一語言的流程。
關於工具部分：
- 可以用詞彙表概念，來記錄統一語言，詞彙表是必須要共同維護，當統一語言一旦發生變化，所有成員繼續更新詞彙表。
- 行為：Checkin、使用案例、事件風暴、領域故事來捕捉行為。
領域故事註記：領域故事是用來描述故事的時候，會使用不同圖示，主要對焦使用，在操作這一部分的時候會使用跟使用者有感的圖示，會有共鳴，在圖示的使用凸顯出標示出來圖樣的獨特性與表達意義，整理完整個圖示之後，就會很好的故事捕捉。- From Kim Kao
事件風暴註記：EventStorming 則有另一個風貌，他也是要聚焦所有人的共通理解，但採以倒敘法的方式，去蕪存菁， 希望能夠在最小的發散空間中，找到共識。 另外結合他當時出生的時空背景，事件驅動當時正熱，所以事件風暴產出的所有層級的產出物，也都能夠跟不同人交流，但也很快地給予指引如果你需要引入 domain event pattern ，那就相得益彰- From Kim Kao
與相關利害人員的合作的有效提問
筆者認為既然領域驅動設計，它是帶有變化同時也是富有哲學，也是要思考和稍微大膽假設，這時候要發揮有效提問的威力。
筆者自己整理的的一些提問，甚至也是可以給自己一些啟發思考，適當的時候可以發揮有效提問的威力。
- 為了提供這個業務價值，我們能做的最小可能的事情是什麼？
- 這個系統需求來自何處？
- 需求的優先級是如何確定的？
- 誰是主要的需求持有人，他們的主要關注點是什麼？
- 這個系統會如何為業務提供價值？
- 這個系統將如何改進當前的業務流程或結果？
- 如何衡量這個系統對業務的影響？
- 如果不建構這套系統會發生什麼情況？
- 現有的業務會面臨哪些挑戰或風險？
- 不實施這個系統會對客戶或內部利益相關者造成什麼影響？
- 如果我明天關掉伺服器，誰會是第一個注意到的人？為什麼？
- 你如何驗證這個系統是否正確運作？
- 我們如何快速獲得使用者的反饋？
- 使用者反饋的最佳渠道是什麼？
- 如何確保反饋能夠迅速影響系統的改進？
- 這個系統的最低可行產品（MVP）應該包含哪些功能？
- 哪些功能是必不可少的，哪些可以後續追加？
- 我們如何確保MVP在最短時間內為使用者提供價值？
- 這個系統的成功會帶來哪些其他機會？
- 我們如何衡量這個系統的成功？
- 成功的標準是什麼？如何量化？
- 我們的關鍵績效指標（KPI）是什麼？
- 你最早能在什麼時候知道這個系統對你是否有價值？我們如何做到這一點？
- 為什麼我們選擇現在解決這個問題？
- 這個系統的開發和部署對其他部門有什麼影響？
- 這個系統的長期維護計劃是什麼？
- 我們如何確保系統能夠持續運行並適應未來的變化？
- 誰將負責系統的維護和更新？
- 有哪些潛在的挑戰或阻礙我們實現這個系統的目標？
- 我們如何預見並提前解決這些挑戰？
- 是否有可以參考的成功案例？
元哥的筆記
