“?領域驅動設計的背后，需要開發(fā)者不能只專注于眼前功能的實現，而應該能夠從全局去了解業(yè)務，并充分的將業(yè)務吃透，以可傳承的知識的形式融入到開發(fā)過程中，只有這樣才能促進產品更好的開發(fā)。”

01

—

傳統(tǒng)項目管理模式，讓設計成為累贅

作為一名資深軟件行業(yè)從業(yè)者，我以前一直從事項目開發(fā)。在項目執(zhí)行過程中，往往會采用快速開發(fā)模式，按照軟件工程的基本流程建立一套項目軟件管理模式。這個流程大概是這樣的：1，需求調研：大概花費合同周期的六分之一時間來進行需求調研，需求調研環(huán)節(jié)力求對用戶需求進行全面的掌握，并整理成需求規(guī)格說明書。2，總體設計和詳細設計：花合同周期六分之一的時間進行項目的總體設計和詳細設計，詳細設計必須覆蓋所有需求，甚至需要精確到偽代碼的編寫。3.項目部署：剩下的時間進行項目的現場實施工作。項目的周期和項目的范圍往往各不相同，為了保證軟件的質量，上述每一個環(huán)節(jié)都非常重要，哪個環(huán)節(jié)的缺少都會對項目完成無法彌補的困難。

有時候，有的軟件公司往往為了更快的完成項目，會把軟件設計人員和開發(fā)人員分成兩支不同的組織，一支專門進行軟件的設計工作，完成甲項目設計后就快速的投入到乙項目的設計過程中。而研發(fā)任務留給研發(fā)團隊來完成，如果遇到設計上的問題，再由設計團隊對軟件設計進行調整，由開發(fā)團隊進行實現上的完善。某種意義上講，這種模式已經成為軟件工業(yè)上的主流模式，無數家軟件公司正是靠這種方式實現了一個又一個的復雜項目的。

然而，這種模式并非完美無缺，他也造成了一系列問題，尤其是單純從設計角度來說。例如，由于過份的重視設計，每個開發(fā)者只能從某個細節(jié)入手進行代碼的實現，而可能不知道這個功能在整體項目中的位置，缺乏了對項目的整體思維。例如，由于設計人員本身知識面也好，技能也好，可能導致設計出來的成品根本不符合需求，后期需要花大把的時間進行調整，最終導致設計文檔成為沒用的負擔。

02

—

敏捷開發(fā)，解放生產力，從拋棄文檔開始

大型軟件公司優(yōu)先意識到這個問題，并對這個模式進行了深入研究，推出了新的理念，極限編程和敏捷開發(fā)。在敏捷開發(fā)模式中，1，首先要求要拋棄臃腫文檔。2，沖刺，以一段時間作為一次沖刺，例如，以兩周為一次迭代周期，發(fā)一次版本。3，建立里程碑。4，使用看板。5，建立用戶故事和統(tǒng)一建模語言來表達一個項目。6，項目組的每一個成員都是團隊不可或缺的部分，盡可能的在一個地方辦公。7，每天一次例行站立會議。由于敏捷開發(fā)極限編程解決了許多現實問題，成為大家廣泛使用的行業(yè)標準。

互聯網公司將敏捷開發(fā)用到了極致，然后建立了一套自己的產品發(fā)布流程。這個流程有可能是以兩周為一次迭代；產品開發(fā)周期為五個步驟，需求，原型設計，界面設計，功能開發(fā)，測試，發(fā)布；使用看板和站立會議，確保任務良好的執(zhí)行。等等。

?對于互聯網公司而言，時間就是生命，誰最先開發(fā)出優(yōu)秀的產品，意味著最先搶占先機。從單純的功能角度來看，互聯網公司的產品往往功能點數量并不會很多，因此在短時間內會把每個功能做到極致。一方面，從需求層面來說，要做到滿足百分之八十用戶的普遍需求，要細化和固化需求，原型設計力求完美，界面設計力求精確到像素點，文案要經得起考驗。功能開發(fā)層面，選擇最成熟的技術方案，做最穩(wěn)定的功能，確保更高的質量和更穩(wěn)定的性能。由于前期準備工作充分，在研發(fā)階段的工作量實際上已經越來越少了。于是，開發(fā)階段的沖刺也意味著更側重于單純的應用實現，不再需要寫方案，畫流程，設計數據庫，最后才實現功能。? ? ?

03

—

領域驅動，讓程序員心中有碼，一劑良方？

?????從上述過程可以看出來，現有的產品研發(fā)模式，實際上已經拋棄了研發(fā)設計過程，而更專注于功能實現，開發(fā)者的唯一目標就是最快的時間完成任務，不需要太多的想法，不需要過度的設計，純粹的功能實現而已。問題是，功能設計真的可以丟棄嗎？

??? 在互聯網公司飛速發(fā)展的背后，往往需要更加職能化，專業(yè)化的團隊，產品開發(fā)的背后，實際上是分工明確小團隊集體智慧的結晶。但是，由于缺失了研發(fā)設計環(huán)節(jié)，就可能導致研發(fā)過程中，功能的開發(fā)全憑開發(fā)者的個人經驗。對于簡單的業(yè)務，尚且能夠掌控，稍微復雜一點的業(yè)務就可能需要付出一定的代價才能勉強應付了。由于功能開發(fā)取決于個人經驗，就可能導致模塊的開發(fā)，從短期來看滿足了眼前的應用指標，但是卻為后期的發(fā)展留下了弊端。隨著原有開發(fā)者工作職責的調整，或者離職，將最終導致憑經驗開發(fā)的功能模塊成為無人能維護的神之領域。

????? 在這樣的背景下，領域驅動設計成為普遍的選擇。實施領域驅動，往往需要由領域專家對系統(tǒng)進行分析，將系統(tǒng)抽象化，然后建立相應的領域模型。實際上領域驅動設計，領域建模同樣是非常重要的部分。即團隊應使用統(tǒng)一的語言建立軟件領域模型，并根據模型來指導開發(fā)，其模型應該是能夠自我解釋，讓人通過模型可以理解開發(fā)者的意圖。通過領域驅動設計，讓不同的開發(fā)者根據應用場景進行模型設計之后，再按照一致性的規(guī)范實現功能，最終可以有效的保證產品研發(fā)質量的提升。領域驅動設計的背后，需要開發(fā)者不能只專注于眼前功能的實現，而應該能夠從全局去了解業(yè)務，并充分的將業(yè)務吃透，以可傳承的知識的形式融入到開發(fā)過程中，只有這樣才能促進產品更好的開發(fā)。然而，領域驅動真的是一劑萬能的良方嗎？

原文地址: https://www.cnblogs.com/xiyuanMore/p/10028574.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的领域驱动设计，让程序员心中有码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。