回顧前端
領域驅動是十五年前，由Eric Evans提出的解決軟件工程複雜性問題的方法，做者從本身多年軟件開發的角度出發，經過引入領域驅動設計的概念以及一系列戰略設計模式和戰術方法，爲混沌的軟件開發領域帶來了一縷陽光。編程
在過去的許多年，我經歷了從技術崗位到管理崗位的變化，也深深的意識到，每個軟件的設計與實施過程之艱辛，缺少一些科學的管理方法，只會讓人疲於奔命，毫無積累，尤爲是對於開發過程而言，看似枯燥乏味的編碼過程，卻充滿了更大的變數。後端
例如，在之前傳統企業開發中設計系統架構時，每每會使用三層架構，用戶界面層，業務層，數據訪問層上手就來，可是卻看似三層分立，可是因爲開發者開發過程當中出現的一些不規範問題，容易在用戶界面層和數據層中堆積大量的冗餘代碼，而中間的業務層反而很是單薄，代碼行不多，僅僅只是實現對象的輸出而已。用戶界面層和數據訪問層就很容易成爲腐化代碼，隨着需求的變動，容易變成大泥球系統。設計模式
尤爲是那些核心模塊的用戶界面層代碼，輕易就突破了上千行，甚至上萬行，這些代碼並不是徹底都是因爲不規範的操做形成的，必定程度上也是因爲個別開發者的代碼不規範，造成的破窗效應。無論發生了什麼，這些代碼最終成爲一座屎山。若是再加上古人寫的存儲過程，對不起，我選擇自閉。架構
屎山的命運每每都是同樣的，要麼重構成功，得以逆天改命，要麼被公司拋棄，成爲企業發展過程當中的一座重要里程碑。然而，每每很多代碼都是一種用戶需求的體現，不管是重構或拋棄，都意味着對於某些需求點的放棄。框架
需求控制或不控制？工具
用戶需求就像一個關在籠子裏的獅子，控制或不控制，這是個問題。學習
對於互聯網公司而言，必定程度上來講，需求來源於產品經理的靈感乍現，或來源於對競品(被抄襲品)功能的把握，不一樣產品經理對於產品的規劃老是不盡相同，以及老闆和用戶的反饋也是產品需求變化的緣由，需求的累積也會讓開發者爲了修改而疲於奔命，並且面向互聯網的產品每每比項目型軟件成品面向更大的羣體，擁有更長的生存週期，開發者爲了應對需求而不節制的更改，容易成爲試錯，甚至會影響企業的生存。測試
因此使用領域驅動設計方法對後端的結構進行改造甚至中臺化改形成爲一種很是有效的解決方案，而對於面向用戶的前臺，以及爲前臺而生的BFF則因爲更側重於用戶數據交互，而被排除於領域控制以外，(即 Backend For Frontend)（固然，過分的依賴前端表現層，也容易形成前端代碼的冗餘，事實上前端和客戶端代碼也最容易成爲屎山，這是後話，就不贅述了。）編碼
除互聯網公司須要領域驅動的方法外，傳統軟件企業也一樣須要，在企業發展過程當中，積累的無數項目，大部分項目都存在一些廣泛性的共性，那就是爲了盲目追求實現，而忽略了軟件代碼的健壯性和可維護性，可否把功能強推下去，取決於項目經理對於甲方的控制力，一旦掌握優秀溝通技巧的關鍵崗位離職，這些項目都將成爲一個個不知什麼時候會爆發的地雷。軟件企業項目的複雜性，有別於互聯網企業的面對業務快速裂變帶來的變化，每每更側重於業務層面的規模複雜，一個系統的大幾百個功能點，如何保證質量，時間，成本三者的平衡，這是個恆古不變的問題。
需求讓軟件充滿變數、而規模、質量屬性也一樣會影響到軟件的變化，要打破僵局，或許，領域驅動看似是一種不錯的選擇。
看似破解之道
然而，領域驅動的實踐過程卻充滿坎坷，主要在於 Evans的原書，知識密度之稠，遠甚於開發者熱衷的技術話題。要解決某些技術問題，依託互聯網的資源，或許能很快找到解決問題的方法，可是面對領域驅動設計，卻讓人望而生畏，許多人都說雖然據說這個概念的時間不在短暫，可是卻總以爲沒有入門。
單純的從概念上看，引入的統一語言，領域存儲庫，實體，值對象，聚合根，限界上下文，上下文映射等名詞，理解上彷佛很容易，可是要付諸實踐卻並不是易事。尤爲還須要把這些東西引入到企業實戰過程，更是難上加難。領域驅動設計方法，並不像那些技術書籍通常，拿着書上的方法，總能在本身公司找到能夠實踐的點。 Evans的書也好，其餘書也好，都只是方法，而不是一套行之有效，立刻就能使用的方案，須要團隊花費大量時間去應用實踐。
例如，一種最多見的領域驅動架構的實踐是簡單四層的領域驅動分層結構，在不能有效理解關注度分離的前提下，架構代碼一樣能成爲屎山，並且彷佛因爲開發者知識傳承的缺失，極其容易讓人難以理解和更不用說代碼質量的提高，只能成爲倡導者實現我的價值提高的練兵場。
我的想法
我我的認爲，領域驅動設計方法，做爲一種解決複雜問題的應對之道，確實值得企業對其持續關注，可是否有一種可以便捷的方法，讓參與者可以更快的將這麼好的方法論在產品研發過程當中融匯貫通，造成更高效的應用過程呢，下面是我根據一些討論和學習過程，造成的一點思考，但願能給你們帶來一絲啓發。
1，如何開始改變企業文化？這是來自於《實例化需求》中提出的一個問題，做者的原意是認爲要實踐TDD，須要進行文化變革，事實上實踐DDD或許一樣如此。康威定律指出：一個組織拿出的技術方案設計，其實是一個組織溝通方式的體現。你的組織真的準備好開始接受這種思想的考驗了嗎？這是個問題。
二、確保你獲得管理層的支持。這也是來自於《實例化需求》中的原話，毫無疑問，若是缺少管理層的承認和支持，過程變動成功的概率幾乎爲零。
三、忘掉敏捷、忘掉領域驅動、忘掉概念。因爲領域驅動設計方法的看似晦澀難懂，容易讓組織實踐領域驅動的人陷入學院派或教條主義的誤區，這表如今：組織者更傾向於使用專家給出的標準術語對領域驅動設計的方法進行解讀而缺少與企業實際相結合的形式。我我的認爲，爲了更好的推廣領域驅動設計的應用過程，不該該侷限於教條主義，不要過度關注於概念、框架或自動化的工具，而是把領域驅動設計過程，解釋成一種發現需求、解釋需求之間的相關性、收集實例、設計測試、以及造成可自解釋的開發代碼的過程。
四、從一個小項目和簡單項目開始，探索創建一套行之有效的方法。從一個業務結構清晰、容易細分出應用場景和業務活動的項目出發，避免陷入大項目難以控制邊界的過程，並且大項目若是沒能更好的實施，只會一發不可收拾。有網友說，因爲項目需求的極度不肯定性，因此他以爲有必要引入領域驅動設計的方法來解決這個問題，我我的認爲，這樣的作法只會致使項目更加一發不可收拾，尤爲是在一個學習能力並很差的組織中開展領域驅動設計實踐、且你們都對這套理論只知其一;不知其二的前提下。
5，從產品語言中提煉統一語言。axure軟件的流行，讓經過原型文檔這種可視化需求表達成爲主流。原型語言與需求的高度貼近，也便於產品研發團隊從中造成統一語言。
6，造成可用的產品術語表。從統一語言出發，造成能夠指導編程的術語表，並造成對應的中英文對照表，能夠便捷的爲開發過程提供變量命名的規則，尤爲是許多開發者自己的英語水平就不是特別好，若是造成這樣的規則，或許能爲代碼的開發過程帶來許多便利。
7，從統一語言和需求中提煉用例圖。按照張逸老師的說法，用例或用戶故事應該知足6w特性，能夠嘗試站在用例的角度思考這樣的問題：
- 到底誰是用戶？須要執行這一活動的角色究竟是誰？
- 爲何須要查詢功能？
- 究竟要查詢什麼樣的內容？
- 爲何須要了解分配給個人任務狀況？
8，從用例圖和業務流程中識別限界上下文。不必一開始就採用四色建模法，採用比較簡單的領域場景分析的用例分析方法進行分析，一樣是不錯的選擇，例如從分析業務活動間的語義相關性，也是一種值得嘗試的方法。
總結
人生三境界：看山是山，看水是水；看山不是山，看水不是水；看山仍是山，看水仍是水。大概技術領域也一樣如此。
回到一個古老的問題，有人問：如何給一個變量命名，詞窮了怎麼辦？專家的回答是，按領域驅動設計的方法對變量進行命名。這就是實踐領域驅動設計的大師高論，已經到了看山仍是山的地步。而普通開發者們，老是看了幾篇領域驅動設計的文章，就會覺得嗯，我遇到的這些問題，用領域驅動能解決，而後，就陷入一堆概念之中不可自拔。
實踐是檢驗真理的惟一標準，惟有真的使用一個項目開始實踐，才能真正體會領域驅動設計的精髓。領域驅動設計思想，是一種充滿魅力的軟件理論方法，然而要把這套理論真的用起來，依然須要經歷一個重新手到高級新手，再到勝任者、精通者和專家的學習過程。本文也一樣屬於一位處於新手村學習者的我的看法，班門弄斧，期待能拋磚引玉，措辭多有不當，還望海涵。
參考資料：一、Eric Evans《領域驅動設計·軟件核心複雜性應對之道》
二、張逸 《GitChat講座：領域驅動設計實戰》
三、Gojko Adzic《實例化需求》
ps:我本不想打廣告，不過我以爲張逸老師的課程確實講得挺不錯的，有興趣能夠關注一下。
