提出問題
如果你去面試，被大公司工作20年的資深技術總監問一個問題“說說你對軟件工程的理解”，你會怎麼回答呢？是不是會像我一樣一臉懵逼，一個問題就讓人回到了小學。沒有經年的編程和架構經歷，沒有對問題本質的深入探究，恐怕任何回答都會顯得非常蒼白。
探索歷程之編程本質
有了問題和好奇心之後，令你印象深刻的問題就會在一段時間內充斥你的腦海。讓我回答對軟件工程的理解，可能我會先從“軟件工程”的定義說起，他應該是一個一級學科，下面包含的範圍非常廣泛，比如計算機科學、光電信息工程、媒體信息工程、自動化控制、通信工程等。
我自己比較熟悉的是計算機科學相關，而計算機科學又是包羅萬象，日常工作可歸之爲“編程”一類，寫的業務代碼居多，中間件和架構也佔一部分。
拿自己熟悉的編程來說，問題就變成了“什麼纔是編程的本質”，我如果把這個問題回答好了，以點破面，也算是能勉強回答總監提出的問題了。
那麼什麼是編程的本質呢，看到左耳聽風的一篇專欄文章（強烈推薦耗子大神，專欄地址），大致觀點如下：
編程 = 算法 + 數據
算法 = 邏輯 + 控制
用圖來表示：
如果對一個表單做驗證，用邏輯+控制的思想，可以這麼寫：
var meta_create_user = { form_id : 'create_user',
fields : [
{ id : 'name', type : 'text', min_length : 3 },
{ id : 'password', type : 'password', min_length : 8 },
{ id : 'repeat-password', type : 'password', min_length : 8 },
{ id : 'email', type : 'email' }
]
};var r = check_form(meta_create_user);上面meta_create_user是“要做什麼”，也就是邏輯。下面check_form是“怎麼做”，也就是控制。
這個觀點對我有非常大的啓發，引發了我很多思考。
探索歷程之架構設計
根據上面的觀點，那麼在架構設計層面，邏輯+控制的思路能否行得通呢？
正好我最近被另一個問題困擾，那就是隨着業務的複雜，架構如何才能不僵化？比如一個企業服務CRM系統，多租戶、多業務線，而且業務線之間耦合還非常重，隨着業務線的增多，代碼開始變得錯綜複雜，無數線頭糾纏在一起，剪不斷、理還亂。再把多租戶考慮進去，就相當於在線頭上又掉上了油漆。
老人扎進了修復bug的海洋，新人理不清業務線。出現這種情況，問題源頭也好找：架構沒做好。
可是架構怎麼做？面向對象的五大原則（SOLID，即單一職責原則，開閉原則，里氏替換原則，接口隔離原則和依賴倒置原則）說起來頭頭是道，設計模式用起來得心應手，SOA的理念爛熟於心，分層的思想也面面俱到。還能要求架構師什麼呢？
雖然很委屈，但也很焦急。
人找不到答案的時候，往往是視野出了問題，也就是視野太窄造成困於原地。
放出去看看業界有什麼樣的解決方案麼？那些聰明勤奮的人恐怕早遇到過這樣的問題。
還真被我找到了，這就是領域驅動設計，簡稱DDD。這種思想簡直讓我大開腦洞，印象最深刻的有兩點：1、程序員要深入瞭解業務，瞭解業務之後建模；2、建模是構建一種共同的語言，這種語言架構師、領域專家、產品經理都能看得懂，而且就用這套語言溝通並一起完善它。
這種思想好啊，熟知領域知識說不定還能在代碼層面進行微創新，真是振奮人心。
有了綱領，就是有了方向，接下來要考慮的就是怎麼在編程層面的落實了。
還是老辦法，這個思想出來了這麼久，肯定有聰明人做過落實的這個事兒啊，何不參考之？麻煩就麻煩在有很多人做了實現，但開源的卻太少。
在Github上找一找，真發現了一個阿里同學寫的框架：https://github.com/alibaba/COPA
看過他的設計和博客文章後，也是驚爲天人，非常感謝significantfrank的分享！
探索歷程之融合
如果你和我有一樣的困擾，建議你認真看一下COPA的理念。
接下來我們再來看領域驅動設計和邏輯+控制之間存在什麼關係呢？
其實想要踐行DDD，必然要熟練的應用到很多設計模式，我們以設計模式中比較經典的策略模式來看一下他們之間的關係，比如一個商品優惠的策略：
有三種優惠方式，分別是普通打折（比如9折），滿減，期限內的特價。我們看到Strategy下的三個實現就是邏輯，而Context的組合拼裝就是控制。
策略模式比較簡單，回到領域建模，在COPA框架中分了三層，其中Service Facade可以看成是控制，Domain裏都是邏輯，Infrastructure裏則是數據了。現在再來看，從微觀到宏觀，編程 = 算法 + 數據 ，算法 = 邏輯 + 控制 這種思想可謂是歷久彌新！