很多人擔心程式設計是個青春飯，覺得30歲以後程式碼就寫不動了，35歲以後就應該轉型做管理。Gevin覺得這個大可不必擔心，做不做管理之類的隨緣，程式設計也不是青春飯，而是一種可以做到“live and learn”的技能。不過，程式碼寫到一定程度之後，技術還要繼續提高或者升維的，架構師就是一個自我提升的不錯方向。架構設計雖然與做開發緊密相連，但試圖透過量變引發質變貌似還是困難的。做架構師也是要掌握方法論的。今天，Gevin分享一下自己在架構設計上的一些思考。
1. 為什麼要做軟體架構設計？
做軟體架構是為兩件事服務的：業務架構和業務量級。
業務架構和業務量級都是從每個具體專案的實際應用場景中提煉出來的。
業務架構是對業務需求的提煉和抽象，開發軟體必須要滿足業務需求，否則就是空中樓閣。軟體系統業務上的複雜度問題，可以從業務架構的角度切分工作交介面來解決。設計軟體架構，首先是要保證能和業務架構對的上，這也是從業務邏輯轉向程式碼邏輯的過程，所以軟體架構的設計為開發指明瞭方向。另外架構設計也為接下來的開發工作分工奠定了基礎。
業務量級表現在儲存能力、吞吐能力和容錯能力等，主要是軟體運維期業務的複雜度。做軟體架構設計，是要保證軟體有能力托起它在業務量級上的要求的，如果軟體到執行使用期廢了，前面所有的工作都付諸東流了。不同的業務量級，對應的軟體的架構複雜度是不同的，所以對於不同的專案，業務量級不同，架構設計也不同。
做業務架構必須與其面向的實際應用場景相匹配，由於每個產品或專案的業務場景均有所不同，所以每次做新的軟體開發前，必須先設計軟體架構，試圖不經分析直接套用先前的架構方案，十有八九會讓當前的系統在某個點上報出大問題導致推翻重來，更不要說直接拿別人的現成架構方案了。
所以每個軟體在開發前，都要結合自己的應用場景設計適合自身的軟體架構，現成的架構方案只能借鑑，不能直接套用。
另外，由於業務架構和業務量級也會不斷調整或長大，軟體架構也不是一勞永逸的，會隨業務不斷調整。
2. 為什麼做業務架構？
我工作中很多情況下，當大家提到架構的時候，往往會直接往軟體架構上去靠攏，經常會不自覺的直接讓做研發的同事或所謂的軟體架構師去做架構設計了，這都為我們的軟體專案的順利開展埋下了隱患。所以，關於為什麼做業務架構，我可以結合實際工作中見過的坑來解釋。
業務架構是左右一個軟體專案能否順利開展的總綱，軟體架構是業務架構在技術層面的對映，合理的開發分工也應該基於業務架構去做。如果沒有業務架構，軟體開發會很盲目。 業務架構是需求和開發的匯聚點，需求是否做到位，功能開發是否到達預期目標，都以此為依託。我們在工作中遇到的一些問題，如研發的人說需求做的不到位，而做需求的人會質疑需求做到怎樣對開發而言才算到位，為什麼開發出的東西和使用者要的不一致，這些從根上說，沒有把業務架構梳理清楚是源頭，沒有在此達成共識，想在由此往上展開的細節上達成共識成本更大。
所以，我們在軟體專案上，應該回歸本位，基於業務架構去做軟體開發，在全面動工之前，先在業務架構上達成共識。雖然有時不梳理業務架構，軟體也能做出來，但這要麼是業務邏輯簡單，要麼是我們有充裕的時間。如果想高效的、目標導向的做軟體，業務架構要重視。
業務架構是樹型結構，是可以不斷細化，一直分解到最末端的葉子節點的。對於軟體開發而言，以業務架構為依託，架構師和開發者能比較清晰的看到系統的業務全貌，架構師能更方便的去分析系統複雜度，分解業務邏輯，做好開發的分工。
站在軟體專案的角度看，專案前期做好業務架構設計，對整個專案的開發具有重要意義。例如對於比較類似的業務系統，可能業務架構在比較粗的顆粒度上是一樣的，而在細化過程會不一樣。做專案時，當手頭有一個現成的系統，現在要做一個需求類似的專案時，大家可能會首選嘗試用現成的系統去覆蓋新專案，以求利益最大化，該想法能否實現，就可以透過業務架構來衡量，如果沒有業務架構，接下來的工作會非常盲目。我在工作中就遇到過，做市場的同事發現兩個業務領域存在一致的業務需求，打算用我們在A領域完成的AS系統直接去應對B領域的需求，以為只要在細節之處做簡單修改即可，結果在系統落地過程中，很多功能模組都重寫了。最終的結果，不是拿AS系統去應對AB兩個領域，也沒做到把AS系統改造為適用於兩個領域的ABS系統，而是以不斷改造AS系統的方式，為B領域做出了一個獨立的BS系統。
這是開發和專案經驗不足導致的，再深挖一下問題點，可發現正是由於業務架構沒做到位、沒有以業務架構指導軟體架構設計導致的。由於兩個業務系統都沒有做好業務架構的分析和設計，所以我們很難看出兩個系統有多少差別，也無法確定用一個業務系統去覆蓋另一個領域的業務的想法有多大的可行性或改動量。相反，如果兩個業務領域都事先梳理的業務架構，我們可以很清楚的看到，從哪個節點起兩邊的業務邏輯開始出現分叉，從而透過進一步的評估可以得知改動的複雜度，如，是不是隻要從分叉節點開始重新功能實現就好了，還是說該變動還會影響到分叉點以上的一些節點，如果它的上級節點改動了，它的兄弟節點要不要調整等等。
所以對於這個案例，如果事先做好了業務架構，是可以比較準確的對軟體系統的開發做出預判的，對接下來的工作安排具有指導意義。（從開始就奔著做一個獨立的系統，與不斷遇到問題不斷改造已有系統直至系統被完全更替掉，無論在專案管理還是在工作體驗上，都是完全不同的。）
3. What’s More？
順著上面的思路，關於業務架構和軟體架構，還能再擴充套件一下。
由於業務架構是軟體開發的總綱，軟體架構是在計算機層面對業務架構的對映，所以業務架構變化，必然會導致軟體架構的調整；而這與軟體架構或框架的存在並不矛盾。我們之所以會有一些通用的軟體架構模式，或者軟體框架，是由於這些都是常見的、通用的業務邏輯的抽象，例如做網站最經典的MVC架構模式，就是在比較粗的顆粒度上，業務架構向軟體架構轉換時的一種通用且適用的對映方式；而各類web框架，那是在軟體層面實現業務功能時那些基礎功能點的抽象化和標準化。這就像樂高的各種基礎積木，而各種樂高模型的搭建還是要靠圖紙，其中，類比中的對應關係見下表：
| 樂高 | 軟體 |
|---|---|
| 模型對應的實物 | 軟體預期 |
| 對實物的分析和分解 | 業務架構 |
| 圖紙 | 軟體架構 |
| 模型 | 軟體成果 |
依託於兩個架構的設計，專案團隊的人員分工也是可以得到落實的。工作分解的主要過程，其實就是不斷梳理業務邏輯，提煉核心業務生命週期，剝離非核心業務生命週期的過程，凡是能夠剝離出來的，都是與核心業務邏輯松耦合的非核心業務，可以分出去獨立完成，而一個業務的生命週期內部，往往是高內聚的，開發成員之間配合緊密，管理和協作如果不到位，人員增減都會降低效率。
工作分工的事情姑且一提，挖個坑以後又機會繼續填~ :P
注：轉載本文，請與Gevin聯絡
歡迎關注我的微信公眾賬號
