讀張逸的領域驅動設計筆記

    張逸的《領域驅動戰略設計實戰》地址，付費的，價格￥59，還能接受。

    領域驅動設計可能會給你帶來的收穫，下面幾點來自於原文，建議讀者閱讀原文:

1. 領域驅動設計是一套完整而系統的設計方法，它能帶給你從戰略設計到戰術設計的規範過程，使得你的設計思路可以更加清晰，設計過程更加規範。
2. 領域驅動設計尤爲善於處理與領域相關的高複雜度業務的產品研發，經過它能夠爲你的產品創建一個核心而穩定的領域模型內核，有利於領域知識的傳遞與傳承。
3. 領域驅動設計強調團隊與領域專家的合做，可以幫助團隊創建一個溝通良好的團隊組織，構建一致的架構體系。
4. 領域驅動設計強調對架構與模型的精心打磨，尤爲善於處理系統架構的演進設計。
5. 領域驅動設計的思想、原則與模式有助於提升團隊成員的面向對象設計能力與架構設計能力。
6. 領域驅動設計與微服務架構天生匹配，不管是在新項目中設計微服務架構，仍是將系統從單體架構演進到微服務設計，均可以遵循領域驅動設計的架構原則。

 

    領域驅動設計(Domain Driven Design,DDD)是Eric Evans提出的綜合軟件系統分析和設計的面向對象建模方法。它改變了傳統軟件開發工程師針對數據庫進行的建模方法，從而將要解決的業務概念和業務規則轉換爲軟件系統中的類型一級類型的屬性與行爲，經過合理運用面向對象的封裝、繼承和多態等設計要素。仔細想一想，咱們在開發項目時，是否是隻是思考數據庫的設計，圍繞着數據庫進行各類操做的呢！

    領域驅動設計是一套方法論，它創建了以領域爲核心驅動力的設計體系，具備必定的開放性。領域驅動設計強調領域模型的重要性，並經過模型驅動設計來保障領域模型與程序設計的一致。因此必定要甄別出領域模型？

    領域驅動設計貫穿了整個軟件開發的生命週期，包括對需求的分析、建模、架構、設計，甚至最終的編碼實現，乃至對編碼的測試與重構，真是這樣?

    領域驅動設計圍繞着領域模型進行設計，經過分層架構(Layered Architecture)將領域獨立出來。表示領域模型的對象包括：實體、值對象和領域服務，領域邏輯都應該封裝在這些對象中。領域邏輯都封裝在這些對象中？這是否是意味着富血模型。這樣嚴格的設計原則能夠避免業務邏輯滲透到領域層以外，致使技術實現與業務路基的混淆。

    

    戰略設計會控制和分解戰術設計的邊界與粒度，戰術設計則以實證角度驗證領域模型的有效性、完整性、一致性，進而以演進的方式對以前的戰略設計階段進行迭代，從而造成一種螺旋式上升的迭代設計過程。

    面對客戶的業務需求，由領域專家與開發團隊展開充分的交流，通過需求分析與知識提煉，以得到清晰的問題域。難點在於需求分析、知識提煉。輔以分層架構與六邊形架構劃分系統的邏輯邊界與物理邊界，界定領域與技術之間的界限。以後進入戰術設計階段，深刻到限界上下文內對領域進行建模，並以領域模型指導程序設計與編碼實現。若在實現過程當中，發現領域模型存在重複、錯位或缺失時，再進而對已有模型進行重構，甚至從新劃分限界上下文。

    經過對問題域進行分析和建模，識別限界上下文，利用它劃分相對獨立的領域，再經過上下文映射創建它們之間的關係，

 

    學會對設計的本質思考，不要只限於設計概念的掌握，要追求對設計原則與方法的融匯貫通。

 

軟件複雜度的成因

1. 理解力：軟件系統的規模、結構
2. 預測能力：變化

控制軟件複雜度的原則

    致使軟件複雜度的成因是規模、結構、變化三要素，要控制複雜度，就須要對他們進行各個擊破。

1. 分而治之、控制規模，必定要拆爲小的。
2. 保持結構的清晰與一致
3. 擁抱變化

    可進化性、可拓展性、可定製性。

    可進化性：可劃分設計單元的邊界，肯定各個設計單元應該履行的職責以及須要與其餘設計單元協做的接口。因爲每一個單元有本身的邊界，邊界內的實現細節不會影響到外部的其它單元，因此，咱們很容易的替換單元內部的細節，保證他們的可進化性。

    可拓展性：首先要識別軟件系統的變化點，常見的變化點包括業務規則、算法策略、外部服務、協議標準、數據格式、業務流程、系統配置等。處理這些變化點的核心就是"封裝"，經過隱藏細節、引入間接等方式來隔離變化、下降耦合。

    可定製型：感受可定製性與可拓展性有點相似。

 

 

 

 

 

    有些地方，還不理解，更新中......