領域驅動之我見—回眸

領域驅動之我見—回眸

公司最近在推動研發體系員工技能圖譜學習，其中對技術經理有一項基本要求是領域建模能力。關於領域驅動設計，埃文斯前輩出版過一本書《領域驅動設計：軟體核心複雜性應對之道》，想必大多軟體工程師都有讀過，也對領域驅動設計有不同的見解，我的理解領域建模也就是面向對象建模。

我本身並非科班出身，原本是個地道的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行業實踐多年而不自知的領域建模，而如今在接觸過很多面向流程的互聯網軟體開發後，確被正式提上理論高度。