領域驅動設計之我見-面向物件思維
領域驅動設計之我見-面向物件思維
公司最近在推動研發體系員工技能圖譜學習，其中對技術經理有一項基本要求是領域建模能力。關於領域驅動設計，埃文斯前輩出版過一本書《領域驅動設計：軟體核心複雜性應對之道》，想必大多軟體工程師都有讀過，也對領域驅動設計有不同的見解，我的理解領域建模也就是面向物件建模。
我本身並非科班出身，原本是個地道的Giser，大學期間學的第一門語言是C語言，繼而又學習了C++，也曾從事過幾年的C++開發工作。入門學習C語言時，感覺計算機語言就是對大腦思維的一種抽象，像數學的計算公式一樣，將思維符號化，然後使用符號計算代替人腦的推理。當開始學習C++時，感覺進入了一種全新的狀態，我開始使用計算機語言模擬這個世界，使用類來模擬一個看得見摸得著的實體，而不在是C語言那樣簡單的將一串思維符號化了。這種程式設計思維反過來影響現實世界的看待問題的方式，當我面對複雜問題時，如何根據問題的上下文對問題進行歸類，劃分屬性，理清所屬關係，進而理出一個可行的方案，一步一步解決問題。
最開始做軟體設計是一個課堂作業，做一個使用MFC開發一款CAD軟體。設計思路很簡單：定義一個基類graphic，然後派生出line、arc、rect分別代表線、弧、多邊形；再定義一個基類graphicStyle，然後派生對應的style；最後通過MFC的document捕獲滑鼠輸入，並繪製相應的圖案。如下：
如上是一個典型的面向物件的設計方案，將現實世界的點線面抽象為計算語言中的一個個類，每個類包含自己的屬性資料和方法。
然而，做了幾年C++之後在一個不巧的機會，開始轉做Java開發，進入網際網路軟體領域，雖然Java語言相比C++語言，是更加純粹的面嚮物件語言，然而縱觀各個Web產品程式碼，哪裡還有面向物件可言，幾乎清一色面向流程進行開發與維護，就是所謂的失血模型。從大的方向來分，所有的類分為兩種，一種是承載資料的資料模型，只含有get和set方法；另一種是不承載資料的無狀態類，所謂的事務指令碼。這種開發，讓整個軟體像是一個大木桶，一個服務就是一個木片，需要新開一個功能就從服務介面到資料庫一擼到底，這樣的開發對於一個小型的軟體來講，非常好用，能夠使軟體快速成型，而且對於開發團隊來講，也比較好分配工作，每人一片，基於資料庫模型，擼完就OK了。然而對於一個大型的專案，或者一個長期維護的專案來講，事務指令碼之間的相互呼叫，錯綜複雜，這簡直是噩夢。
因此，領域驅動設計，被公司作為軟體工程師的一項基本技能，特別是對於技術經理必須具有良好領域建模能力。對於我而言，這個曾經在GIS行業實踐多年而不自知的領域建模，而如今在接觸過很多面向流程的網際網路軟體開發後，確被正式提上理論高度。