本隨筆謹用于記錄本人學習《領域驅動設計-軟件核心復雜性應對之道》的過程和收獲，愿與大家共享之

初寫于2024.07.24，學習未竟，隨筆伴行--

本人于工作期間閱讀該書，發現很多值得反復學習的方法和思考方式，隨筆記錄；

興之所至，興盡即止---

本文是針對面向對象開發人員所編寫的，如不合適，請自行斟酌是否繼續閱讀---

接下來正文開始：

前言

作者結合自己的開發經驗，在書中為作出設計決策提供了一個框架，并為討論領域設計提供了一個技術詞匯庫

本書討論的前提是：

1.大多數項目中，主要的焦點應該是領域和領域邏輯；ps:所謂領域和領域邏輯即項目完成后落地實施時所面向的人群標簽，所涉及的人群標簽，設備和物流等物理和非物理的實體和概念性實體等以及它們之間的數據流轉方向和方式等；

2.復雜的領域設計應該是基于模型；ps：MBD允許客戶和工程師模擬和驗證在開發早期的設計，即通過早期先設計業務流程的方式？在設計初期確定好業務的流程，至少是大概流程，后續基于此流程進行軟件的開發；

其次，本書主要是面向“敏捷開發過程”這一新體系：

敏捷開發是一種基于迭代開發的新的開發體系；它倡導極限編程，反對預先設計。盡管體系承認設計決策對軟件的重要性，但它更傾向于將精力投入到促進溝通和提高項目快速變更能力的工作中。

因此，在敏捷開發的過程中，開發人員至少更少的設計，每次只利用最簡單但能實現目標的方案即可，并在后續的開發中進行不斷的重構，最終得到滿足客戶真正需要的設計

（該思想類似于貪心算法，在每一步都尋求局部最優解，從而獲取最終的全局最優解）

但是這樣的開發體系也存在一些問題：

1.在尋求局部最優解的過程中，可能會導致最終結果偏離全局最優解，這是所有的貪心算法的通病；

2.敏捷開發的思想要求開發人員每次都使用最簡單有效的方案來實現本次設計目標，這可能導致前期的設計不足會影響到后期開發的設計難度；

3.敏捷開發對軟件開發人員的設計能力有一定的要求，需要開發人員具有敏銳的設計感和在設計中的縝密思考能力；

第一部分 運用領域模型

第一章 消化知識

軟件的作用是為了滿足業務的使用需求，其核心是幫助用戶解決領域相關的問題；這意味著一個軟件的設計不應該圍繞軟件本身，而是要圍繞著解決領域中的問題為核心，并且以提升客戶的使用體驗為宗旨對軟件進行優化和改進

1.有效建模的要素：

（1）模型和實現之間的綁定；軟件的作用是為了滿足業務的需求，所以軟件和業務之間是存在天然的聯系的，溝通過程中的模型和模型的實現也是存在天然的聯系的，溝通和迭代應該是基于他們之間的這種聯系的；

（2）建立了一種基于模型的語言；一種基于模型的語言，而不是簡單的通過日常語言來溝通。語言是溝通的重要工具，合適的工具能夠大幅提升工作效率，溝通也一樣，尤其是在軟件設計領域的溝通中，使用基于模型的語言既能保證溝通的效率也能保證所有的溝通都是基于模型和實現的綁定關系進行的；

（3）開發一個蘊含豐富知識的模型；對象具有行為和強制性規則，模型不僅僅是一種數據模式，它還是解決復雜問題的不可或缺的部分，其包含各種類型的知識；

（4）提煉模型；在模型被持續迭代優化的過程中，其核心的屬性和動作應該被保持，一些一開始覺得重要但后續覺得不重要的信息應該被移除；

（5）頭腦風暴和實驗；不存在所謂的“靈光一閃”，所有的靈感都來源于豐厚的積累，所謂的靈感只是在無數個不好的方案被廢棄掉后終于被通過的普通的念頭；

 2.知識消化

沒時間寫了，先下班，后面再補....

續寫：

（1）知識消化一般是在開發人員的領導下，由開發人員和領域專家組成的團隊共同協作；（而整體項目的推進個人來看應該與之相反，應該由領域專家帶領開發人員開進行整體上和細節上的設計和開發）

（2）在瀑布模式中：業務專家與分析員(需求管理一類的角色)進行溝通，然后程序員和需求管理員進行溝通詳細需求并開發，這種方式中知識的流動是單向的，而且不會累積（除非你主動學習記錄）；

（3）在迭代模式中，開發人員依然是根據業務專家的描述來構建整個功能體系，并在此基礎上進行擴展。一名優秀的程序員會自然的抽象出一個具有更高的可擴展性的模型，但如果這個過程如果缺少業務的幫助，很容易得到一個幼稚的模型；

（4）模型聚焦于需求分析，通過良性循環加深團隊成員對領域的理解，是一個不斷演化的過程。

3.持續學習

當我們開始編寫軟件的初期，我們所知的信息與完成整個項目所需要的全部知識相比具有很大的差距。

項目知識往往分散在很多人，設備，文檔中，其中夾雜著一些無關信息。這種無知往往會導致我們在開發初期對項目的難度產生很大的誤判；

同時，所有的項目都存在知識的丟失。因此一個團隊需要有意識的積累知識，并且保持持續學習。

4.知識豐富的設計

業務活動和規則與所涉及的實體，都是領域的核心

知識消化所產生的模型能夠反映出對知識的深層理解，因此在模型發生改變的同時，開發人員需要對實現進行重構，從而反映出模型的變化。

當建模不再局限于尋找實體和值對象時，知識才能夠被充分吸收。（要理解領域中的業務活動和規則的底層邏輯，而不是只做簡單的增刪改查）

5.深層模型

隨著對領域和需求的理解加深，最初的模型元素可能會被丟棄，或者改變角度。

知識消化是一種探索，它永無止境。