對業務建模

標籤：

這不是什麼新鮮話題，但是最近在維護一個之前同事遺留下來的項目，有了一些感想。其實我很久都不做具體的業務了。很長一段的時間主要在負責基礎設施以及商務工具方面的開發，所以我做的事情，往往並不需要和具體的業務打交道，其實這樣挺困難的，關鍵在於我並非設計者，設計者是其他的專職設計師，他學曆高，工作時間也長，但是可惜的是，他在web系統的架構以及設計上並沒有多少的經驗，所以其實事情也挺難做的。

而現在接手的這個項目是一個很純粹的業務系統，沒有太多的自主設計，用的是標準javaEE的那一套，從技術上面來說是無可厚非的。但比較糟糕的是整個系統沒有對業務進行建模，而是把業務分布在眾多的RESTful API以及SQL語句上了。我覺得這其實是一種維護的災難，太多的API把業務分割的支離破碎，根本不知道這些API什麼用。系統的目錄結構是按照技術來劃分的，這種劃分方法我必須吐槽一下，業務被隱藏在毫無意義的技術名詞下面了，大大增加了人的理解難度。

所以我覺得應該對業務建模，至少在程式中能看到業務的脈絡，而並非是一堆技術名詞。而且這樣也比較容易讓人意識到各個業務模組之間的界限，不會把所謂的DAO什麼的service什麼的搞得過於的臃腫。之所以容易選擇用技術名詞來命名系統中的檔案夾，我覺得主要是因為根據業務命名是比較困難的，這是因為：

1. 業務總在發展和變化

2. 業務沒有明顯的界限

3. 業務之間總是相互牽連

4. 無論業務多麼的複雜，實現的技術總是不變的

似乎我們按照技術來組織我們的代碼，也沒有什麼不對的。

所以組織代碼有兩種情況：

1. 技術-》業務

2. 業務-》技術

第一種方式最常見，使用spring的人一般都是這種風格。你會發現其代碼結構中，頂級的檔案夾命名都是技術名詞，什麼DAO，什麼service之類的。一個業務相關的代碼往往分散在這些檔案夾裡面的各個類中。這樣的做的後果就是，永遠不知道業務在哪裡，看不見，摸不著。隨著業務的變化這些檔案夾中的內容都在變化不止，最終也無法抽象出一個模型以便重用。代碼的複用性為：零。

這種代碼裡面隨處可見大量注釋掉的代碼，以及各種補救措施。代碼膨脹的速度驚人，一個巨大無比的焦油坑已經出現在不遠的地方了。吐槽一下：在很久之前，我們學習UML的設計方法的時候，一定需要對業務建模的，後來有了EJB，這個也需要對業務建模。後來有了WEB系統的流行，以及Spring的出現。但不知道是哪個天才開始程式裡面再也看不見業務模型了。業務是不可能消失的，不建模的一個重要原因是，這些業務可能十分的簡單，但是它不可能永遠都是簡單的。特別是如果你希望積累或者希望複用的話。以技術為核心的這些項目被複用是十分困難的，因為你需要精心的拆解它們，和重做其實差不多了。

第二種方式，我覺得比較好。它有一個很重要的優點，就是可以複用。並且，從某種程度上來說，抽象的業務並不依賴具體的技術實現，這樣對於業務的最佳化很有好處。此外，對於大多數的公司來說，業務才是真正有價值的東西，技術不是核心，技術僅僅是價值的載體，價值體現在業務裡面。但是它有一個最大的缺點，就是難。對實現者要求很高，搞出一個很好的模型比較困難。就是這樣。不是能夠通過讀書，讀學位就能達到的，需要大量的實踐，以及比較高的天賦。 

對業務建模