引子，軟體工程沒有銀彈
回到十年前，第一節軟體工程學的課堂上，我們的老師就告訴了我們一句真理，軟體工程沒有銀彈，這句話說的是，軟體工程領域，從來沒有一種思想或理論能夠帶來成倍的效率提公升。不知不覺，十年過去，我們大概可以看到，軟體開發新技術日新月異，新語言層出不窮，但是無論哪種技術，都不見得相對於其所對標的技術取得了成倍的提公升。技術尚且如此，理論就更不用說了。
領域驅動設計，近年來受到技術圈的廣泛追捧，主要得益於微服務技術的發展。一千個讀者有一千個哈姆雷特，而不同的人往往對這種理論有不同的看法。如果問乙個.net開發者領域驅動是什麼，大概他會說是abp架構。abp架構作為完全按照領域驅動設計思想構建的技術架構，目前得到了社群的廣泛追捧。然而，領域驅動架構和領域驅動設計，依然是道和術的區別，開發者在學習領域驅動架構的同時，也應該了解領域驅動設計。那麼領域驅動設計究竟是什麼的東西？由於時間和篇幅有限，我無意通過**介紹如何實現乙個領域驅動的功能，而是希望把領域驅動設計的基本思路進行梳理，期待能通過我的梳理，拋磚引玉，給大家帶來啟迪。
一，領域驅動設計，不錯的選擇
作為現代軟體工業發展的產物，敏捷開發和極限程式設計，實現了生產力的解放，通過拋棄傳統研發模式中留下的臃腫的設計文件，實現了勞動生產力的提公升，無數網際網路公司，依靠靈活的開發手段，為產品插上了快速開發的翅膀。開發者們不用加班，分分鐘就把**擼完，然後把產品質量關把好，發布，嗯，早早的就回家休息了。然而，隨著產品功能的逐漸增加，團隊自然而然也需要擴充套件。可是，團隊成員越來越多，**質量成為乙個難以把控的問題。如何保證產品功能的一致性？如何保證功能符合產品的需求？管理者們不厭其煩，每天開會必須提開發質量，必須強調制數命名，注釋，設計原則，設計模式，然後每天一次整合，**審查估計已經不現實了。於是，作為面子的產品質量尚且有測試把關，而作為內臟的**質量本身，成為上帝的骰子，好與壞全靠開發者們的自覺性和經驗。
冰山，在軟體產品華麗外表之下，究竟深藏著多少問題？
領域驅動設計在這樣的場景下推出來的一種理念。軟體系統的複雜度是開發者們沒辦法避免的客觀情況，而根據領域的實際情況，建立模型是解決問題行之有效的方法。在實際過程中，我們需要領域專家與開發者一起，共同努力，以一種特殊的方式來進行溝通，並通過模型將實際生活中的問題抽象化。
1 統一語言在日常討論過程中，我們需要跟領域專家討論，往往大家都是自己行業內的專家，也意味著大家都有自己的表達問題的方式和自己的理解，這有可能導致需求支離破碎。例如對對方表達的術語不了解，會形成雞同鴨講的情況。因此，需要建立乙個能夠互相溝通理解的語言環境，例如，互相的交流雙方的術語，並試圖利用雙方都能理解的詞語進行問題的分析。也許在最開始這樣共同語言並不能很好的運作，但是卻可以在後期逐漸完善。我們的開發者應該定期的了解領域所在行業的業務知識，擴充自己的知識面，這也有利於我們與領域專家的交流。
2 建模和畫圖
在我們工作過程中模型無處不在，不管是在紙上繪製的簡單模型，或者使用專業軟體繪製的各種模型，都是模型。領域驅動設計本身，依然依賴於模型驅動設計。學會建模對於廣大開發者來說，都是一項基本技能。可以說，**語言是為了與其他開發者進行溝通交流，那我們建立的各種軟體設計模型將極大的方便不同領域的人員進行交流。建模也可以稱之為語言的一部分利用uml建立類圖，是一種可以比較易於接受的方式。我們可以採用以下手段來建立領域模型。
1)建立乙個與實現繫結的模型。初版的模型也許很簡陋，但是它可以成為乙個基礎，然後在後期逐漸完善。
2)建立一種基於模型的通用語言或表達形式和機制。通過通用語言讓參與專案的所有人理解模型。
3)開發乙個蘊含豐富知識的模型。模型不是單純的資料結構，它更是各類知識的聚合體。
4)提煉模型，模型應該能在專案過程中動態改變，發現新的概念就加進來，過時的概念就適時移除，避免臃腫。
5)頭腦風暴和實驗。模型在於實踐和應用，它需要專案參與者共同的努力，而頭腦風暴是發揮集體智慧型的良好方式。對模型進行實驗或者進行場景的模擬，有利於讓模型更符合需求。
當然，對於領域專家而言，不同型別的模型也許無法理解，例如類圖可能過於複雜，可以使用畫圖的形式，通過解釋性的圖形或者模型，可以讓不同層次的人都能獲得一致的理解。
3 設計文件
設計文件依然是不可拋棄的重要資料，雖然設計文件可能不利於維護，卻仍然不可拋棄。畢竟開發過程中，通過**和模型，有可能會導致關鍵資訊的丟失，而且有的不能直接參與討論的領域專家需要通過文件才能了解之前討論的情況，甚至可能畫圖會形成很多歧義，這也需要解釋性的文件才能說清楚。為了讓文件變得更加有效，不建議重複贅述已知的資訊，而關鍵資訊更改後，應該盡量保持最新。
完全依賴**或架構的自解釋特性目前似乎已經成為大家的普遍習慣，但是**可能存在歧義，或者有的方法本身就無法表達方法的本質含義，最終導致**成為無法理解的神之領域，這種問題已經不是乙個單純的領域驅動架構能夠解決的。如果為了讓**來解釋模型，我們所有人必須時刻抱著一絲不苟嚴於律己的態度，才能寫出完全符合領域模型的**，問題是這種方式現實嗎？
4 概念總結：
1)領域就是問題域，有邊界，領域中有很多問題；
2)任何乙個系統要解決的那個大問題都對應乙個領域；
3)通過建立領域模型來解決領域中的核心問題，模型驅動的思想；
4)領域建模的目標針對我們在領域中所關心的問題，即只針對核心關注點，而不是整個領域中的所有問題；
5)領域模型在設計時應考慮一定的抽象性、通用性，以及復用價值；
6)通過領域模型驅動**的實現，確保**讓領域模型落地，**最終能解決問題；
7)領域模型是系統的核心，是領域內的業務的直接沉澱，具有非常大的業務價值；
8)技術架構設計或資料儲存等是在領域模型的外圍，幫助領域模型進行落地；
三、問題思考
掌握建模和基本的步驟，意味著一切剛剛開始。道阻且長，行則將至，領域驅動設計，不僅僅是一種簡單的建模思想或技術架構，更是一種挑戰。在選擇之前，是否需要思考一下，這一套體系，真的適合在你的團隊中執行麼？如果要切實的執行，還需要付出多少代價？尤其是對於領域模型而言，如果缺乏合理有效、而且持續迭代的設計，你難道不覺得最終所有的模型僅僅只是一種資料結構設計嗎？
posted @
2018-12-07 23:15
溪源more 閱讀(
...)
編輯收藏
領域驅動設計，讓程式設計師心中有碼 三）
正如西方古典哲學在現代社會逐漸式微，成為少數內心豐滿者們填充自己精神世界的寶貴食物，uml也這樣 網際網路技術飛速發展的今天，各類軟體設計思想層出不窮，正是站在uml和其他各種軟體基礎理論巨人的肩膀上，成就了當代軟體產業的輝煌。如果說軟體工程是在虛擬的世界描繪出人類對於這世界一切大千萬物的美好想象，...
讓程式設計師設計介面的後果
每個軟體開發人員的內心深處，都有乙個當美工的小我，而且呼之欲出。但倘若他真的出來了，你就麻煩了。不可避免的是，你的使用者也慘了。joseph cooney提到過乙個關於 對話方塊 的案例 有個開發人員需要乙個介面，也就是 1 2個文字框，於是他自己建立了乙個 對話方塊 也許他只是想試驗某些東西，而且...
表達 程式設計師心中的痛
最近，我們專案組重寫了以前的 採用了新的基於外掛程式結構的框架，還是比較爽的。雖然我對其中的一些設計 比如ui模組，仍然使用mfc等等 還持有懷疑態度，但不可否認的是，這比以前那些看了讓人有一種被 感覺的 不知道好了幾千倍。因為這個平台是要對外開放的，要允許第三方使用者可以在此基礎之上進行二次開發，...