「正如西方古典哲學在現代社會逐漸式微，成為少數內心豐滿者們填充自己精神世界的寶貴食物，uml也這樣；網際網路技術飛速發展的今天，各類軟體設計思想層出不窮，正是站在uml和其他各種軟體基礎理論巨人的肩膀上，成就了當代軟體產業的輝煌。」
如果說軟體工程是在虛擬的世界描繪出人類對於這世界一切大千萬物的美好想象，那麼也許uml思想應該是這虛擬世界的古老哲學。他就像盧梭在法國大革命前，描述在《社會契約論》一書中，對這自由世界的期待。書中，敘述了社會結構和社會契約、主權和權利，和運作模式。這本書，奠定了世界民族制度的基石，深刻的影響了世界的發展史。
01—領域驅動建模與模型驅動設計
領域驅動設計認為，不合時宜的設計或者沒有設計，對於複雜專案來說，根本就是舉步維艱。而且，如果某些複雜專案確實嘗試使用某些形式的領域模型，但是沒有把模型與**的編寫緊密的聯絡起來，這樣的模型也無法確保軟體的正確性。在實際專案中，領域模型的建立也是分析知識，消化吸收的過程，如果分析與設計存在分歧，那麼在分析和設計活動中所獲得的知識將毫無價值。
領域驅動設計使用模型驅動設計的方法來解決這些問題。它期望通過不再將分析模型和程式設計分離開，尋求一種能夠兼顧兩方面需求的單一模型。軟體系統的每個部分，都在模型中體現。即使更加深層次的領域概念，也應該如此。模型不應該只滿足設計需求，也要滿足開發需求，更需要支援健壯性的通用語言。
領域驅動設計中採用模型驅動設計的模式，期待達到的目標是，通過模型獲取用於程式設計和基本職責分配的術語，讓程式**成為模型的表達。同時，也對後期的其他活動造成影響。不同的子系統往往要建立不同的模型，而從需求分析到**過程中，不應該額外設計過多的模型，這意味著，模型是單獨為某一塊業務設計的。02—
uml，為設計而生
為了設計每個子系統的單獨模型，需要對業務進行仔細咀嚼，消化好知識，研究模型的每個選項，並細化為使用的軟體元素，通過uml讓軟體設計本身成為乙個高效運轉，不斷迭代的模式。
統一建模語言（uml，unifiedmodelinglanguage）是物件導向軟體的標準化建模語言。uml因其簡單、統一的特點，而且能表達軟體設計中的動態和靜態資訊，目前已成為視覺化建模語言的工業標準。uml的目標是以物件導向圖的方式來描述任何型別的系統，具有很廣泛的應用領域。其中最常用的是建立軟體系統的模型，但它同樣可以用於描述非軟體領域的系統，如機械系統、企業機構或業務過程，以及處理複雜資料的資訊系統的執行過程等。
前文提到過，uml如同《社會契約論》這本書一般，對軟體工程學進行了定義，它主要是通過一系列模型和關聯關係來進行約定的。可以說，uml是軟體工程學中最基本的正規化，這種正規化最終影響了我們所設計的軟體產品的方方面面。
uml系統設計過程中，常見的圖表主要由三種不同應用視角的模型。
1、首先是分別是功能模型，這種模型聚焦於以使用者角度展示系統的功能，例如用例圖。用例圖定義乙個軟體系統中的基本角色型別。用例圖也是一種靜態的圖表，更側重於抽象化系統參與者本身，而不是行為特徵，如同社會契約中的不同社會角色。
2、其次是物件模型，採用物件、屬性、操作、關聯等概念展示系統的結構和基礎，包括類圖、物件圖、包圖。類圖，側重於對物件的狀態和行為特徵進行定義，更加注重於具體的執行層面。其實類圖也是軟體系統中最常見的圖表，通過類圖，可以便於讓開發者了解不同領域之間的關係。物件圖與類圖本質上的作用類似，均代表一種特徵明確的單元物件或者實體，不過與類圖相比，物件圖實際上是偏業務層面，而類圖偏**層面。物件圖和類圖都是邊界清晰的物件，通過狀態，行為，標識進行區分。物件圖是乙個空間或時間維度物件在軟體世界的投影，而類圖是抽象物件的具體實現結構。包圖也是模型物件的組合，通過包圖可以將不同型別的物件按照一定的特徵進行結構化和更加合理的邏輯定義。
3、再次是動態模型，主要顯示系統的內部行為。包括時序圖，活**、狀態圖。時序圖顯示時間維度上不同物件的執行步驟和介面方式，每乙個訊息代表乙個類的操作，或者其他物件的行為觸發。活**，表示物件間正在進行的事件狀態，體現的是物件間在不同階段的狀態切換，活**側重於物件內部，或物件間動態的執行過程中，狀態變化。看起來活**與流程圖類似，但流程圖側重於表現物件間的順序和時間關係。活**也似乎與狀態圖類似，不過區別在於狀態圖表示單一物件的在不同階段的狀態變化。
物件間的聯絡，類似於現實社會中實體物件的權利和義務以及倫理觀念。在uml中，關係很多，而且在不同的版本，或不同的設計軟體中，都有不同形式的關係表現。而常見的關係有泛化，實現，關聯，組合，聚合，依賴等。
【泛化】，作為一種繼承關係，定義父類的特徵和行為，並對子類如何表現這種特徵和行為進行了約束。例如現代語言中的子類和超類之間，就是一種泛化關係。
【實現】，類與介面之間的關係。介面作為契約，而類作為具體執行者，去執行相應的契約。
【關聯】，建立不同類之間的聯絡，這種聯絡包括單向或雙向的聯絡，例如情人之間，互相可以共享對方擁有的資源，而類與類之間建立了聯絡之後，也可以實現對方的某些屬性或行為。
【聚合】，表徵乙個物件和它的子物件間的關係，子物件在其業務範圍擁有一定的獨立權，但是在更大的層面，可能需要父物件類體現。
【組合】，組合關係同樣是表示物件與物件間存在整體與部分間的關係，但子類無法脫離父類而存在。
【依賴】，體現乙個物件的實現需要另外乙個類的協助，缺少依賴性，將導致物件無法運轉。依賴又分成直接依賴，間接依賴，迴圈依賴，雙向依賴等說法，過於複雜的依賴關係將提高系統的耦合性。 03—
結語如我本文開頭所說，uml其實是一種古老哲學，它定義了軟體設計過程的基本結構、關係、和職責，對軟體工業的標準化發揮了不可磨滅的共享。因此在實踐領域驅動設計過程中，同樣也應該使用uml這種優秀的建模理論作為輔助，設計和實現符合業務需求、開發模式的軟體系統。
十多年前，我就讀於湘中小城，當時的專業是資訊與計算科學，實際上這是數學系下的乙個交叉學科，我們班大部分同學都是調劑生，而我卻是為數不多的第一志願錄取。在我們專業開設的一堆數字加計算機課程中，最感興趣的是軟體工程，最記憶猶新的也是uml，然而參加工作以後發現，其實應用得非常少，真的是因為它不實用嗎？其實一方面是因為軟體公司的成熟度還不夠，一方面也是盲目的選擇不適合的模式，並不一定能帶來效率的提高，彼之蜜糖，吾之砒霜。應當根據企業實際出發，建立更加利於執行的正規化，形成一套屬於企業自己的、簡約、易於執行、便於擴充套件的約束。uml這種思想其實已經滲透到我們工作中的方方面面，在領域設計過程中，尤其需要使用它來打造更美的設計。
領域驅動設計，讓程式設計師心中有碼（二）
引子，軟體工程沒有銀彈 回到十年前，第一節軟體工程學的課堂上，我們的老師就告訴了我們一句真理，軟體工程沒有銀彈，這句話說的是，軟體工程領域，從來沒有一種思想或理論能夠帶來成倍的效率提公升。不知不覺，十年過去，我們大概可以看到，軟體開發新技術日新月異，新語言層出不窮，但是無論哪種技術，都不見得相對於其...
讓程式設計師設計介面的後果
每個軟體開發人員的內心深處，都有乙個當美工的小我，而且呼之欲出。但倘若他真的出來了，你就麻煩了。不可避免的是，你的使用者也慘了。joseph cooney提到過乙個關於 對話方塊 的案例 有個開發人員需要乙個介面，也就是 1 2個文字框，於是他自己建立了乙個 對話方塊 也許他只是想試驗某些東西，而且...
表達 程式設計師心中的痛
最近，我們專案組重寫了以前的 採用了新的基於外掛程式結構的框架，還是比較爽的。雖然我對其中的一些設計 比如ui模組，仍然使用mfc等等 還持有懷疑態度，但不可否認的是，這比以前那些看了讓人有一種被 感覺的 不知道好了幾千倍。因為這個平台是要對外開放的，要允許第三方使用者可以在此基礎之上進行二次開發，...