领域驱动设计，让程序员心中有码(三）
“正如西方古典哲學在現代社會逐漸式微，成為少數內心豐滿者們填充自己精神世界的寶貴食物，UML也這樣；互聯網技術飛速發展的今天，各類軟件設計思想層出不窮，正是站在UML和其他各種軟件基礎理論巨人的肩膀上，成就了當代軟件產業的輝煌。”
如果說軟件工程是在虛擬的世界描繪出人類對于這世界一切大千萬物的美好想象，那么也許UML思想應該是這虛擬世界的古老哲學。他就像盧梭在法國大革命前，描述在《社會契約論》一書中，對這自由世界的期待。書中，敘述了社會結構和社會契約、主權和權利，和運作模式。這本書，奠定了世界民族制度的基石，深刻的影響了世界的發展史。?
?正如西方古典哲學在現代社會逐漸式微，成為少數內心豐滿者們填充自己精神世界的寶貴食物，UML也這樣；互聯網技術飛速發展的今天，各類軟件設計思想層出不窮，正是站在UML和其他各種軟件基礎理論巨人的肩膀上，成就了當代軟件產業的輝煌。但是也必須承認到，UML就像成為案牘上的新華字典，它也許曾經璀璨奪目，而今卻積滿灰塵。尤其是目前的軟件思想，更多的是側重于更快更好的完成項目，重開發，輕設計實際上是普遍現象。事實上，UML一開始，也是計算機專業課程中一顆難以采摘的艱澀果實，在追求互聯網速度的今天，被大家選擇性的遺忘也是情理之中，但UML是一種非常寶貴的財富，了解UML，并適當的使用，將讓我們真正理解軟件設計的真諦。
?
?
01
—
領域驅動建模與模型驅動設計
?
? ? ? ? 上一篇提到，領域驅動設計的核心是建模。而采用的建模方法就是UML建模。在我們的軟件設計過程中，有兩種截然相反的設計理念。一種理念是，一切皆抽象，把整個系統設計成一張無比巨大的類圖，這個類圖簡直包羅萬象，與當前項目有關的所有方面都一一呈現。另外一種是沒有設計，沒有對象建模，先搭一個快速原型，然后不斷的累積功能，沒有設計模式中需要用到的泛化或抽象的思想。
? ? ? ?領域驅動設計認為，不合時宜的設計或者沒有設計，對于復雜項目來說，根本就是舉步維艱。而且，如果某些復雜項目確實嘗試使用某些形式的領域模型，但是沒有把模型與代碼的編寫緊密的聯系起來，這樣的模型也無法確保軟件的正確性。在實際項目中，領域模型的建立也是分析知識，消化吸收的過程，如果分析與設計存在分歧，那么在分析和設計活動中所獲得的知識將毫無價值。
? ? ?領域驅動設計使用模型驅動設計的方法來解決這些問題。它期望通過不再將分析模型和程序設計分離開，尋求一種能夠兼顧兩方面需求的單一模型。軟件系統的每個部分，都在模型中體現。即使更加深層次的領域概念，也應該如此。模型不應該只滿足設計需求，也要滿足開發需求，更需要支持健壯性的通用語言。
? ? ?領域驅動設計中采用模型驅動設計的模式，期待達到的目標是，通過模型獲取用于程序設計和基本職責分配的術語，讓程序代碼成為模型的表達。同時，也對后期的其他活動造成影響。不同的子系統往往要建立不同的模型，而從需求分析到代碼過程中，不應該額外設計過多的模型，這意味著，模型是單獨為某一塊業務設計的。
?
02
—
UML，為設計而生
?
????????為了設計每個子系統的單獨模型，需要對業務進行仔細咀嚼，消化好知識，研究模型的每個選項，并細化為使用的軟件元素，通過UML讓軟件設計本身成為一個高效運轉，不斷迭代的模式。
? ? ? ??統一建模語言（UML，UnifiedModelingLanguage）是面向對象軟件的標準化建模語言。UML因其簡單、統一的特點，而且能表達軟件設計中的動態和靜態信息，目前已成為可視化建模語言的工業標準。UML的目標是以面向對象圖的方式來描述任何類型的系統，具有很廣泛的應用領域。其中最常用的是建立軟件系統的模型，但它同樣可以用于描述非軟件領域的系統，如機械系統、企業機構或業務過程，以及處理復雜數據的信息系統的執行過程等。?
? ? ? 前文提到過，UML如同《社會契約論》這本書一般，對軟件工程學進行了定義，它主要是通過一系列模型和關聯關系來進行約定的。可以說，UML是軟件工程學中最基本的范式，這種范式最終影響了我們所設計的軟件產品的方方面面。?
? ? ? UML系統設計過程中，常見的圖表主要由三種不同應用視角的模型。
? ? ? 1、首先是分別是功能模型，這種模型聚焦于以用戶角度展示系統的功能，例如用例圖。用例圖定義一個軟件系統中的基本角色類型。用例圖也是一種靜態的圖表，更側重于抽象化系統參與者本身，而不是行為特征，如同社會契約中的不同社會角色。
? ? ? 2、其次是對象模型，采用對象、屬性、操作、關聯等概念展示系統的結構和基礎，包括類圖、對象圖、包圖。類圖，側重于對對象的狀態和行為特征進行定義，更加注重于具體的執行層面。其實類圖也是軟件系統中最常見的圖表，通過類圖，可以便于讓開發者了解不同領域之間的關系。對象圖與類圖本質上的作用類似，均代表一種特征明確的單元對象或者實體，不過與類圖相比，對象圖實際上是偏業務層面，而類圖偏代碼層面。對象圖和類圖都是邊界清晰的對象，通過狀態，行為，標識進行區分。對象圖是一個空間或時間維度對象在軟件世界的投影，而類圖是抽象對象的具體實現結構。包圖也是模型對象的組合，通過包圖可以將不同類型的對象按照一定的特征進行結構化和更加合理的邏輯定義。
? ???3、再次是動態模型，主要顯示系統的內部行為。包括時序圖，活動圖、狀態圖。時序圖顯示時間維度上不同對象的執行步驟和接口方式，每一個消息代表一個類的操作，或者其他對象的行為觸發。活動圖，表示對象間正在進行的事件狀態，體現的是對象間在不同階段的狀態切換，活動圖側重于對象內部，或對象間動態的執行過程中，狀態變化。看起來活動圖與流程圖類似，但流程圖側重于表現對象間的順序和時間關系。活動圖也似乎與狀態圖類似，不過區別在于狀態圖表示單一對象的在不同階段的狀態變化。? ?????
? ? ? ? 對象間的聯系，類似于現實社會中實體對象的權利和義務以及倫理觀念。在UML中，關系很多，而且在不同的版本，或不同的設計軟件中，都有不同形式的關系表現。而常見的關系有泛化，實現，關聯，組合，聚合，依賴等。
? ?? ??【泛化】，作為一種繼承關系，定義父類的特征和行為，并對子類如何表現這種特征和行為進行了約束。例如現代語言中的子類和超類之間，就是一種泛化關系。
? ? ? ? 【實現】，類與接口之間的關系。接口作為契約，而類作為具體執行者，去執行相應的契約。
? ? ? ? 【關聯】，建立不同類之間的聯系，這種聯系包括單向或雙向的聯系，例如情人之間，互相可以共享對方擁有的資源，而類與類之間建立了聯系之后，也可以實現對方的某些屬性或行為。
? ? ? ? 【聚合】，表征一個對象和它的子對象間的關系，子對象在其業務范圍擁有一定的獨立權，但是在更大的層面，可能需要父對象類體現。
? ? ? ? 【組合】，組合關系同樣是表示對象與對象間存在整體與部分間的關系，但子類無法脫離父類而存在。
? ? ? ? ?【依賴】，體現一個對象的實現需要另外一個類的協助，缺少依賴性，將導致對象無法運轉。依賴又分成直接依賴，間接依賴，循環依賴，雙向依賴等說法，過于復雜的依賴關系將提高系統的耦合性。?
????
03
—
結語
?? ? ? ?如我本文開頭所說，UML其實是一種古老哲學，它定義了軟件設計過程的基本結構、關系、和職責，對軟件工業的標準化發揮了不可磨滅的共享。因此在實踐領域驅動設計過程中，同樣也應該使用UML這種優秀的建模理論作為輔助，設計和實現符合業務需求、開發模式的軟件系統。
? ? ?十多年前，我就讀于湘中小城，當時的專業是信息與計算科學，實際上這是數學系下的一個交叉學科，我們班大部分同學都是調劑生，而我卻是為數不多的第一志愿錄取。在我們專業開設的一堆數字加計算機課程中，最感興趣的是軟件工程，最記憶猶新的也是uml，然而參加工作以后發現，其實應用得非常少，真的是因為它不實用嗎？其實一方面是因為軟件公司的成熟度還不夠，一方面也是盲目的選擇不適合的模式，并不一定能帶來效率的提高，彼之蜜糖，吾之砒霜。應當根據企業實際出發，建立更加利于執行的范式，形成一套屬于企業自己的、簡約、易于執行、便于擴展的約束。UML這種思想其實已經滲透到我們工作中的方方面面，在領域設計過程中，尤其需要使用它來打造更美的設計。
相關文章：
領域驅動設計，讓程序員心中有碼
領域驅動設計，讓程序員心中有碼（二）
原文地址: https://www.cnblogs.com/xiyuanMore/p/10129529.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的领域驱动设计，让程序员心中有码(三）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .net core i上 K8S(六).
- 下一篇： .net core上 K8S(七).ne