百般武藝為哪般, 業務域是核心

"業務域,是軟體的核心價值所在。"

專案經理與架構師是天生的敵人,短期看這是對的,長期來看,他們是真正的朋友,是戰略朋友。沒有專案經理專案會死得很快;然而沒有架構師,公司會死得很慘。

專案經理的角色和作為,我仍比較容易理解。一則,他以短期為目標,人都是短視的,所以專案經理的角色比較接近人的直覺;二則，專案經理的活動也是我們常見,常說的,例子故事較多。而對架構師,我們卻頗多誤解,至少也是含混不清。

我曾經問過很多開發人員,你的五年計畫是什麼?幾乎無一例外的回答都是想成為一名架構師。特別是在校學生,幾乎是脫口而出。這是乙個有意思的現象。我的理解,一、他的職業方向是技術方面,想在技術上有所建樹,架構師是乙個明顯的技術標桿,從這一角度，我很肯定他們的回答。二、業界對軟體職業兩條線,專案輕理和架構師,這個理論已經深入人心，也不錯。三、架構師成為脫離「開發苦海"的代名詞,頗值商榷。

架構師不是乙個只管"架構"的傢伙,他更是乙個集大成者。各種技術,無論高雅還是低俗都是他囊中的**。還有低俗的技術嗎?有的,非常多連剛入門的開發者都覺陳舊的好東西。

什麼,繼承,你老土了吧?開口只會說設計模式都不敢說你是做開發的。現在,都是雲,雲開霧照的雲。nooooosql一聽這名字就得勁。否定錯誤就是正確,這世上哪有沒有瑕疵的東西。所以，我們的口號就是否定一切！好了，扯太遠了。

首先，倉儲模式(repository）。repository不是dal！雖然它們如此的接近,有的架構設計就把它們合二為一了。repository用於物件持久化,dal是從資料庫中運算元據。仍然迷惑,看不出兩者的區別？

讓我們來乙個思維的遊戲：

一般三層架構的文章用來解釋dal層的好處，用資料庫的變更做例。比如:之前系統是用orcal資料庫,現在要換作sql server。如果,我們使用了dal這一層，就可以很容易實現，而不觸及系統其它。

我這裡需要你設想另外一種變更，從資料庫儲存資料，切換到用檔案系統，如cvs或xml檔案放資料（如果你要想的更高階一點，更酷一點，可以想想用雲儲存）。這時候，dal這一層的隔離已經沒有辦法解決了。而是要更上層,這就是我們的repository。

所以，可以說repository和dal是兩層。自然，這增加了複雜度,你確實需要衡量你系統是否必要。另外，nhibernate可以很好的擔當了dal的角色,同時對repository的支援也很好。應用得當,可以減少很多任務作量。

再回到repository的描述,repository用於對業務域物件持久化。細心的人可以發現,我加了三個字」業務域「。

其次,mvc。mvc不是三層架構。雖然看起來它也分三塊，但決對不是。另外,mvc中的m不是業務域，決對不是,雖然有些系統實現採取了這種方式，把ｍｖｃ的ｍ和業務域物件合二為一，但是原則上它們完全不是一回事。微軟用ｖｍ（view model)代替m還是有點意思的。

mvc最大的目的和功能，是把最終介面相關（v的部分）的東西最大限度的隔離出去，因為這部分是不可測試的，而那些仍然與介面相關，含有大量邏輯（演算法？）的部分抽象出來，或者放入c中，或者放入m中。使得可測試的**的邊界，盡可能推到ui的最前沿。雖然，慢慢現有不少ui測試自動化工具的出現，功能還不錯，但是與單元測試，**直接介面的測試相比，效率和質量還是不可同語。

仍然回到對目的的思索。mvc是為什麼？為了測試？恐怕還不是最終的目的，測試又是為了什麼呢？

單元測試，行為測試，整合測試， 眾多名詞，我不想討論它們之間的差別，作為一類概念，從名稱上，他們只呈現了一半的內涵。還有乙個重要部分被漏掉「自動化」。自動化單元測試， 自動化整合測試，才更為準確。自然，這裡我也不討論非自動化測試，如功能測試，驗收測試。

自動化測試的好處是不言而喻的。前文中mvc提到的測試，就是指提高自動化測試的覆蓋率。對整個系統來說，達到100%的覆蓋率是根本不可能的。在這個大前提下，我們很容易忽略提高自動化測試覆蓋率的重要意義。90%與70%只是數字的區別？讓我麼走近一點，把系統拆分一下再看。整個系統不能達到100%，具體是那部分不行呢？前面提到的view是乙個，資料庫又是乙個，不是完全不能測，理論可以，實際有些麻煩，不值當。還有就是一些外部功能，如發郵件，讀寫檔案。檔案操作這個看來經常用到的功能塊卻是單元測試的大敵。所有這些排除後，再回頭看看，我們可以說剩下的100%能測試，也必須測試，不然就是架構和設計的問題。

剩下的這100%中，很大部分就是業務領域模型，重中之重，難中之難，也是值中的超值。

前面的responsitory也好，mvc也好，看似複雜，其實簡單，簡單在於邏輯固定。昨天，我花了乙個小時，完成了乙個簡單類的新增，現實的功能，從前端controller(我叫command)到服務層，業務類，再到respository及資料庫，只花了乙個小時。因為邏輯簡單固定，相當於乙個表的crud。很多推廣的所謂一站式解決框架，都是用這種情況的典型案例，特別是微軟，從vb開始，到現在的entity framework,最酷的演示就是只要新增幾行資料定義，一分鐘，從介面到後台完成。當然，這比我昨天的手工作業要快得多。但是回到實際的商業軟體開發，從來沒有基於這樣的高效而能一天完成乙個專案。不是嗎，如果按一分鐘乙個介面或者乙個資料表，乙個有100個表的專案已經足夠大了吧？這樣簡單做個乘法，我們不是100分鐘就可以搞定了嗎？實際呢，不用說100分鐘，就是100個小時也不夠。所以，這樣的演示根本沒有含義，可是，很多人卻樂此不疲。

我以前公司，有一位架構師，在ibatis的基礎上，完成乙個所謂框架，可以已經建立的資料表，自動生成業務物件，和crud的**。然後驕傲的宣布，80%的開發工作已經完成。可是之後，專案又開發了兩年。如果說是80%的**量，我可以說是，80%的工作量？我懷疑。

這正是我們很多架構師沒有意識到，或者不願意承認的事實，框架設計好了，架構搭建好了，這才剛剛是個開頭，而遠遠不是結束。

這是百般武藝亮盡的結束， 是業務領域探險的啟程。

百般武藝為哪般, 業務域是核心

業務域,是軟體的核心價值所在。無論是買成型的軟體產品,還是出資開發專案,客戶投資的是軟體的業務價值。專案經理直接為這個目標負責,盡量少的成本,盡量短的時間,生產出高業務價值的軟體產品。架構師則是跨越單個專案,長期為這個目標負責。專案經理與架構師是天生的敵人,短期看這是對的,長期來看,他們是真正的朋友...

「母校」挨罵為哪般？

剛才看了王德華老師的新博文 母校真的可以罵嗎？兩則 裡面提到大名鼎鼎的 根叔 的一句名言 什麼是母校？就是那個你一天罵她八遍卻不許別人罵的地方 俺也來跟著湊個熱鬧，說說 母校挨罵 的事兒。母校 是在其中求學，讀過若干年書 度過了漫長青春歲月最後拿到了她頒發的畢業證 學位證的學校。有些人身在其中之時，...

如此晚睡為哪般

數說魚的記憶只有七秒，我嚴重懷疑自己的記憶力頂多也只有七秒了，最近就連打字都會出現問題，某個字根怎麼都想不起來在哪個鍵，事實上，打字時根本不應該不需要去反應這個問題啊。然後這個 等下 快到連我回一句話解釋一下的時間都趕不及，就顯示要跟對方聯絡需要通過驗證，我只能邊傻眼，邊自責自己智商低情商弱 不過，...