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

2021-06-11 19:13:21 字數 3049 閱讀 6429

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

無論是買成型的軟體產品,還是出資開發專案,客戶投資的是軟體的業務價值。專案經理直接為這個目標負責,盡量少的成本,盡量短的時間,生產出高業務價值的軟體產品。架構師則是跨越單個專案,長期為這個目標負責。

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

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

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

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

什麼,繼承,你老土了吧?開口只會說設計模式都不敢說你是做開發的。現在,都是雲,雲開霧照的雲。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不是業務域,決對不是,雖然有些系統實現採取了這種方式,把mvc的m和業務域物件合二為一,但是原則上它們完全不是一回事。微軟用vm(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%的工作量?我懷疑。

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

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

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

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

「母校」挨罵為哪般?

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

如此晚睡為哪般

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