本隨筆謹用於記錄本人學習《領域驅動設計-軟體核心複雜性應對之道》的過程和收穫，願與大家共享之
初寫於2024.07.24，學習未竟，隨筆伴行--
本人於工作期間閱讀該書，發現很多值得反覆學習的方法和思考方式，隨筆記錄；
興之所至，興盡即止---
本文是針對物件導向開發人員所編寫的，如不合適，請自行斟酌是否繼續閱讀---
接下來正文開始：
前言
作者結合自己的開發經驗，在書中為作出設計決策提供了一個框架，併為討論領域設計提供了一個技術詞彙庫
本書討論的前提是：
1.大多數專案中，主要的焦點應該是領域和領域邏輯；ps:所謂領域和領域邏輯即專案完成後落地實施時所面向的人群標籤，所涉及的人群標籤，裝置和物流等物理和非物理的實體和概念性實體等以及它們之間的資料流轉方向和方式等；
2.複雜的領域設計應該是基於模型；ps：MBD允許客戶和工程師模擬和驗證在開發早期的設計，即透過早期先設計業務流程的方式？在設計初期確定好業務的流程，至少是大概流程，後續基於此流程進行軟體的開發；
其次，本書主要是面向“敏捷開發過程”這一新體系：
敏捷開發是一種基於迭代開發的新的開發體系；它倡導極限程式設計，反對預先設計。儘管體系承認設計決策對軟體的重要性，但它更傾向於將精力投入到促進溝通和提高專案快速變更能力的工作中。
因此，在敏捷開發的過程中，開發人員至少更少的設計，每次只利用最簡單但能實現目標的方案即可，並在後續的開發中進行不斷的重構，最終得到滿足客戶真正需要的設計
（該思想類似於貪心演算法，在每一步都尋求區域性最優解，從而獲取最終的全域性最優解）
但是這樣的開發體系也存在一些問題：
1.在尋求區域性最優解的過程中，可能會導致最終結果偏離全域性最優解，這是所有的貪心演算法的通病；
2.敏捷開發的思想要求開發人員每次都使用最簡單有效的方案來實現本次設計目標，這可能導致前期的設計不足會影響到後期開發的設計難度；
3.敏捷開發對軟體開發人員的設計能力有一定的要求，需要開發人員具有敏銳的設計感和在設計中的縝密思考能力；
第一部分 運用領域模型
第一章 消化知識
軟體的作用是為了滿足業務的使用需求，其核心是幫助使用者解決領域相關的問題；這意味著一個軟體的設計不應該圍繞軟體本身，而是要圍繞著解決領域中的問題為核心，並且以提升客戶的使用體驗為宗旨對軟體進行最佳化和改進
1.有效建模的要素：
（1）模型和實現之間的繫結；軟體的作用是為了滿足業務的需求，所以軟體和業務之間是存在天然的聯絡的，溝透過程中的模型和模型的實現也是存在天然的聯絡的，溝通和迭代應該是基於他們之間的這種聯絡的；
（2）建立了一種基於模型的語言；一種基於模型的語言，而不是簡單的透過日常語言來溝通。語言是溝通的重要工具，合適的工具能夠大幅提升工作效率，溝通也一樣，尤其是在軟體設計領域的溝通中，使用基於模型的語言既能保證溝通的效率也能保證所有的溝通都是基於模型和實現的繫結關係進行的；
（3）開發一個蘊含豐富知識的模型；物件具有行為和強制性規則，模型不僅僅是一種資料模式，它還是解決複雜問題的不可或缺的部分，其包含各種型別的知識；
（4）提煉模型；在模型被持續迭代最佳化的過程中，其核心的屬性和動作應該被保持，一些一開始覺得重要但後續覺得不重要的資訊應該被移除；
（5）頭腦風暴和實驗；不存在所謂的“靈光一閃”，所有的靈感都來源於豐厚的積累，所謂的靈感只是在無數個不好的方案被廢棄掉後終於被透過的普通的念頭；
2.知識消化
沒時間寫了，先下班，後面再補....