DDD
什麼是領域?
來自GPT的回答：領域（Domain）在不同的上下文中可能有不同的含義，但通常它指的是特定知識或活動的範圍。
領域驅動設計分為兩大部分：戰略設計與戰術設計
戰略設計：涉及回答【什麼】與【為什麼】
例如：我們正在建立什麼軟體，為什麼建立它。
戰術設計：是關於【如何】
例如：每個元件如何實作。
什麼是業務領域?
業務領域是定義公司主要活動區域，這是公司為客戶提供服務。
- FedEx提供快遞服務
- 星巴克以咖啡聞名
- Walmart是最廣為人知的零售店之一
備註：一家公司可以多個業務領域，在商業來說也可以多角化經營。
例如：
- Amazon同時提供零售與雲端服務
- Uber是一家共乘公司，提供送餐和共享車服務
領域驅動設計分成三種類型的子領域
- 核心
- 通用
- 支持
關於核心子領域
核心子領域：跟公司與競爭對手不同之處，這可能涉及發明新產品或服務，透過最佳化現有流程來降低成本。
註記：這些是公司表現異於競爭對手的活動，並從中獲得競爭優勢。
關於通用子領域
通用子領域：是所有公司都以相同方式來執行的業務活動。
註記：通用子領域通常很複雜且難以實行，但通用子領域不會為公司提供任何競爭優勢。(這裡指的是不需要創新與最佳化，經過實戰考驗實踐已經廣為使用，所有公司都在使用它們。
例如：多數系統已經有會員認證機制和身分驗證與授權，與其自己研發，不如用現有的解決方案更為合理，因為這種已經有許多其他相同公司測試過和驗證過可行了。
筆者看法：通用子領域有一個隱含的含義，這點我到覺得保持一個保留態度來看，這時候筆者大膽假設思考，我是不是可以從通用子領域的角度來切入，使用出購買一流師父的招數和購買一流工具來強化通用子領域甚至核心子領域，在由通用子領域加入變化，轉換成核心子領域，變成做的更出色且差異化，因為核心子領域是解決高度複雜的問題，那同樣的通用子領域能否進化到複雜子領域這件事，我認為有可能。
關於支持子領域
支持子領域：支持公司的業務，支持子領域並沒有提供任何的競爭優勢。
例如：資料輸入螢幕和ETL的提取、轉換、載入操作，也就是一般的CRUD介面，這些活動區域不會為公司提供任何競爭優勢。
核心子領域是公司將自己與競爭對手區分開來戰略。
通用子領域是一般公司與其他競爭對手使用相同解決方案。
支持子領域是通常不會介意對手複製支持子領域，因為不會影響自身競爭力。
關於DDD的問題空間與解決空間
筆者在看問題空間和解決空間的議題是滿有趣的，來看看問題空間和解決空間的意思，這是從GPT給來的解釋。
1. 問題空間 (Problem Space)
問題空間指的是業務問題或需求所在的領域。這是產品或系統需要解決的現實世界問題的集合。在問題空間中，我們專注於理解業務邏輯、業務流程、規則、約束以及用戶的需求。問題空間通常由業務專家、產品經理和其他利益相關者來定義和描述。
主要特點：
- 領域專注：集中於業務領域的需求和問題。
- 語言：使用業務領域中的專業術語和概念。
- 目標：理解並清晰地描述問題本質。
範例： 如果我們在設計一個電子商務系統，問題空間將包括產品管理、訂單處理、支付流程、庫存管理等業務問題。
2. 解決空間 (Solution Space)
解決空間指的是為了解決問題空間中定義的問題而設計的技術解決方案。在解決空間中，我們專注於如何實現問題空間中的需求和功能，這包括系統架構設計、技術選型、數據庫設計、代碼編寫等。
主要特點：
- 技術專注：集中於技術層面的解決方案。
- 語言：使用技術術語和概念，如架構模式、設計模式、技術棧等。
- 目標：設計並實現技術解決方案來滿足業務需求。
範例： 在電子商務系統中，解決空間包括選擇合適的後端框架（如ASP.NET Core）、設計數據庫結構來支持產品和訂單管理，以及實現支付集成。
兩者的關係
問題空間和解決空間之間的關係類似於業務需求與技術實現之間的關係。DDD強調在解決問題之前先深入理解問題空間，這樣才能設計出符合業務需求的技術解決方案。通常，問題空間中的理解和模型會轉化為解決空間中的技術實現，並在這個過程中保持業務語言和技術語言之間的一致性。
總結
- 問題空間是理解和描述業務需求的領域。
- 解決空間是為解決這些業務需求而設計的技術方案。
關於問題領域和解決方案領域
在領域驅動設計（Domain-Driven Design, DDD）中，Problem Domain 和 Solution Domain 是與問題空間和解決空間相關的概念，但它們更具體地指向業務問題及其技術解決方案。這兩者是理解 DDD 的核心點，以下是它們的詳細解釋：
Problem Domain
Problem Domain 是指業務問題所在的領域，即系統需要解決的業務問題的集合。它涉及對特定業務領域中所有概念、規則和過程的理解。Problem Domain 是 DDD 的核心，因為它決定了系統需要解決的實際問題。
主要特點：
- 專注業務需求：Problem Domain 完全關注業務方面的問題，如用戶需求、業務規則、流程等。
- 語言：使用領域專家的術語和概念，通常是非技術性的語言。
- 目標：確保技術團隊和業務專家對業務問題有共同的理解。
範例： 假設你正在構建一個醫療管理系統，Problem Domain 可能包括病人管理、預約調度、醫療記錄維護等業務問題。
Solution Domain
Solution Domain 是指解決 Problem Domain 中業務問題的技術解決方案。這包括設計、實現、部署和運行系統的所有技術方面。Solution Domain 需要將 Problem Domain 中的業務需求轉換為具體的技術實現，如代碼結構、系統架構、數據庫設計等。
主要特點：
- 專注技術實現：Solution Domain 完全關注如何實現和支持業務需求的技術解決方案。
- 語言：使用技術術語和概念，如架構模式、設計模式、編程語言等。
- 目標：將業務需求轉換為可運行的技術系統。
範例： 在醫療管理系統的場景中，Solution Domain 可能包括選擇使用 ASP.NET Core 來構建後端服務，設計一個 SQL Server 數據庫來存儲醫療記錄，並實現一個基於 REST API 的預約系統。
總結
- Problem Domain（問題領域）關注業務問題及需求，描述「我們需要解決什麼」。
- Solution Domain（解決方案領域）關注技術解決方案，描述「我們如何解決這些問題」。
在 DDD 中，理解並正確建模 Problem Domain 是構建成功解決方案的關鍵，而 Solution Domain 則是將這些模型轉化為技術實現的地方。這種區分確保了技術團隊能夠正確理解業務需求並有效地實現它們。
筆者在看GPT所給解釋，每個人對問題空間和解決空間思考和切入點不一樣，這邊筆者初入看問題空間的時候，要區分的是如何判斷你的問題是屬於簡單還是複雜?
筆者用一個生活舉例
簡單問題，短時間可以解決問題。
例如：今天午餐要吃什麼早餐，就可以找到你喜歡的午餐店，找到你想吃，這個問題就可以解決，或者是1+1 你可以立刻回答2這都屬於簡單問題範圍。
複雜問題牽扯到多個東西範圍變廣時候，問題複雜度就會提高。
例如，你要找全端工程師，要具備前端和後端技能的能力，甚至具備資料庫設計，還要懂Devops或是DDD，這就是複雜問題。
Teddy給了一個對它的詮釋：https://teddy-chen-tw.blogspot.com/2021/01/13.html
但我覺得DDD的問題與解決空間這部分沒辦法完整的傳遞的訊息，這時候可以引用Swardley所提的
- Purpose：我們關心的領域存在哪些問題需要解決或需要達到什麼目的?
- Landscape：我們關心領域的當前狀態是什麼?
- Climate：領域推動力是什麼?我們該如何前進?
- Doctrine：我們應該普及好的做法。
- Leadership：在現有和新領域中我們應該做什麼方案或變動。
總結：DDD其實有很多關於相關詞彙要理解和思考，初期的時候要對這些觀念至少有一些基本認識，也要去反覆思考為什麼?
最後有發現到這些思考的部分，會提煉出自己對DDD的認知與見解。
解決方案戰略角度來看
核心子領域：必須在內部實作，它不能被購買和採用，這會破壞競爭優勢，因為競爭對手也可以這樣使用。
舉個例子：當我會購買他人時間的招數，那別人也是購買時間的高手，也會反之這樣使用。
實行核心子領域關鍵
- 需求會不斷的變化
- 解決方案必須可維護和容易發展
- 需要最先進的工程技術
通用子領域關鍵：採用購買現成產品或採用開源從成本考量思考，從投入時間和精力在內部實行通用子領域會很有效益。
支持子領域關鍵：支持子領域不需要設計模式或是現今工程技術，可以透過程式框架來實作業務邏輯，不會引入意外性複雜度。
參考或引用來源
https://medium.com/wardleymaps/exploring-the-map-ad0266fad59b
https://teddy-chen-tw.blogspot.com/2021/01/13.html
元哥的筆記
