借降本增效之名，探索開閉原則架構設計
作者：京東科技 胡燦海
引語
在我們的研發生產活動中，經常會遇到如下類似的疑惑：
業務和技術在公司組織活動中，究竟應該各扮演什麼樣的角色？
技術的目的是什麼？
研發生產活動中，如何提高生產事故發生的下限？
如何充分提高isv或者外協人員價值最大化？
《人月神話》說優秀程式設計師是普通程式設計師研發效率10倍，如何可以提高研發效率水位線呢？
如何避免《人月神話》指出的「焦油坑」？
如何更好的對老系統進行ddd升級？
這些疑惑單獨看都可以有很多的解決思路，或者從制度層面解決，或者從技術層面解決，或者業務層面解決，等等，甚至也有可能出現某些解決思路按下葫蘆浮起瓢，但如果將這些問題統一起來看，是否能找到他們對應的共性，嘗試從最底層的邏輯找到問題解決的切入點呢？
疫情啟發
新冠疫情持續了三年時間，讓咱們的生活發生了很多與之前不一樣的改變，比較典型的一個現象就是我們在公共場所的椅子上會要求進行隔位相坐。經過長期的觀察，發現很多場所這樣的要求和提示如同虛設。我們不討論政治和經濟，單純從實現設計的維度來思考如何讓這個要求能落到實處，實實在在的幫助我們更好的進行科學防疫。以下是幾個場合的隔位相坐實現方式：
我們拒絕紅燈思維，認為每種實現方式在那時那情那景下都是最優選擇。從這四個實現方式中，我們可以發現從效果和美觀上來看，是可以認為存在一個遞進的關係，極其類似我們的系統的演化過程。假設衛健委給出行政要求，公共場合必須要將隔位相坐落到實處，或許能有人挖掘出一種商業模式，即提供隔位相坐最優解決方案的能力和服務，從中賺取服務費用。畢竟不是每個目標主體都能在當時情景能實現最佳，或者需要更大成本才能實現較佳。
系統實現反思
為了得到高質量的軟體產品，我們是應該把精力更多地集中在提升其中每一個人員、過程、產出物的能力和質量上，還是該把更多精力放在整體流程和架構上？—— 《鳳凰架構》
系統的行為價值 和 架構價值 到底哪個更重要？——《架構整潔之道》
系統是演化發展的，根據疫情隔位相坐實現方式的啟發，系統是否可以以巨人肩膀為起點開始演化發展？
對於以上反思，下面嘗試從一種切面來和大家一起探討。
統一溝通語言
有很多的方案的討論最終達不成一致，很大程度在於雙方溝通語言不統一，即雙方討論問題最基本的基石基礎並不是一致的，所以怎麼討論都不可能達到一致的結論和目標，所以我們首先統一一下溝通語言。
我們知道，咱們作為一個商業公司，最底層的邏輯肯定是商業盈利，那麼我們作為其中的一員，我們每個人有以下三個角色（注：以程式設計師崗位進行分析），每個角色的職責價值嘗試做如下解析：
個人角色
曾有企業家有言：一個企業的邊界取決於其創始人的認知邊界，其實對個人也是如此，一個人的價值大小也是由其認知邊界決定的。個人角色短期來看，對咱們解決方案討論意義並不是那麼重要。這個也不是能很快改變的。暫且忽略影響。
公司職員角色
員工的任何公司任何活動都應該朝著有利於公司市場競爭優勢的方向進行的。甚至可能還關注公司第二曲線，在我們公司文化裡面還倡導第三曲線；
程式設計師角色
我們認為技術的最終目的更應該是降本增效，具體體現為業務初創期低成本快速迭代，業務成長期快速低成本規模化，以及將以上低成本能力抽象成能力光環，從而實現助力業務快速迭代，以及釋放創造力助力管理。
兩個概念
回到本文主題，本文主要是嘗試通過探索開閉原則架構設計來實現降低認知負載，從而達到降本增效的目的。因為在研發活動中，我們的關注點越發散，會越容易降低我們的研發效率，所以本文的目的是想通過系統遵循開閉原則架構進行設計，保證系統的職責的清晰和單一化，以收斂研發的關注，保證程式設計師能集中精力將事情做好。主要從加強系統純潔度維度來嘗試進行闡釋。
開閉原則，耳熟能詳的原則，其比較關鍵的特點在於，系統或者模組的唯讀性，以及和 職責單一原則的一體兩面；如此在我們的研發活動過程中，可以將穩定的需求和 常變的需求，通過組合的方式將不同的模組進行擴充套件。而穩定的需求我們其實是可以進行產品化封裝的。
鳳凰架構的邏輯
鳳凰架構的思想是參考生命系統的可靠性和穩定性，希望通過一系列不穩定的子系統來打造一個穩定可靠的大系統；而其實生命系統的可靠性也不是一蹴而就的，並且也只是一個穩定且發展的文明系統的載體；這個文明系統的演化過程非常類似咱們需求交付的過程；
通常比較主流的觀點對於文明的演化理論是進化論，進化論來源於達爾文的《物種起源》的進化樹，而進化論其實存在未能解釋的空缺，即為什麼進化樹是由單細胞向多細胞進化和低等生物向高等生物進化而不是相反，以及進化與熵增定律和質能方程E=mc²衝突，即進化來源於什麼？有學者提出一套演化理論即「遞弱代償」理論（不討論其爭議性，只分析客觀邏輯），解釋了以上空缺。即從30億年前單細胞到軟體生物到脊柱生物到人類，物種伴隨的文明越發達，而物種的存在度空間會越小，因為單細胞是全能的，從吸收到排洩，以及繁殖都能實現，而人類的組織，已不再是單細胞而是多細胞高度分化成不同功能的獨立的組織，而某個組織也只有某個功能，放棄了單細胞其他大部分的功能。因此隨著文明的愈發達，而文明當前的載體分化程度越高以至於產生了新的物種。而分化的程度越高，誕生出來的新物種的存在度會越低，如同上圖右公式圖，即物種的存在度與系統的文明發達程度成遞弱關係。（參考《物演通論》）
這極其類似我們需求交付過程，即單個系統不再是萬能的，而是分化成不同的小型子系統，而通過每個系統繼續高度的分化和升級，使得整個大系統的能力越來越豐富和強大。
而我們的系統分化的原則就應該是上述的開閉原則和單一職責原則，這才能保證每個系統能獨立的分化和演進，保證了在需求迭代的過程中，整個系統可以不斷的進化為新的業務物種形態，並且進化過程中依然可靠。
在一個系統內，進化的本質是替換部分元件使之成為新的物種，而不是當前物種的升級；而系統最終升級演化的趨勢就是系統內所有元件都能敏捷替換，修改一下路由，很低成本替換元件，這樣優化系統的成本會越來越低。
軟體系統的邏輯
我們再來分析咱們軟體系統的結構，主要分兩部分，一部分是基礎設施，一部分是業務部分；而基礎設施主要是馮諾依曼體系；而在討論開閉原則時，最典型的案例就是馮諾依曼體系；
馮諾依曼體系可以簡化為cpu，儲存，輸入輸出；正是這套擴充套件性非常強的體系支撐著在計算機世界的發展。cpu通過元指令和指令流的分離，資料與計算的分離，並且提供中斷回撥，來落地了開閉原則，保證了多麼複雜的需求的實現都不再需要修改cpu了；而將變化的業務交給輸入輸出;上面的作業系統則將馮諾依曼體系進行了封裝，提供了方便的操作方式。
試想：能否將上層的頁面模式的設計思路也複用底層的基礎設施的設計思路呢？在最外層再提供一層「作業系統」提供使用呢？
再反觀現在行業的各種服務化，SAAS,PAAS,IAAS 其實也就是這種思路的體現和落地。
星鏈的邏輯
貨指的是一些業務側和中臺側的能力，中臺側能力如商品、支付、風險等，業務側能力如賬戶、交易、賬務等。
人包括各類角色，如消費者側的預授信使用者、運營側的推廣人員、商戶側的結算人員等。
場是人與貨發生互動的場所和方式，人可能通過各類媒介如金融APP、商城APP、小程式、H5等與貨互動，通過各類產品與貨互動，通過各類運營方式、不同流量來源來與貨互動。
貨是相對穩定的，一般不是面向特定人和場的，是沉澱的業務和中臺能力，構建貨的能力，消金內部借鑑的是領域驅動設計(DDD)和中臺化的思想，這些能力沉澱下來的是相對穩定的、與場景關係不大的領域原子微服務。
而這個思想不正是開閉原則的另一種表達麼？
業務垂直拓展思考
這是對不同複雜度的系統的一個簡單概括總結，我們的系統可能處於高階別分散式系統的層次，那我們再思考一下我們的業務系統，我們進行垂直拓展的顆粒度能達到什麼級別呢？
從通常ddd的分層的思路來看，我們可以嘗試將系統將應用層，不同場景的聚合中偏使用者端的模組交給 上層接入層，是否可以將接入層單獨抽離成獨立系統，比如交給星鏈來實現（如果不用星鏈可能會比較重），以保證了領域與接入層的相互獨立。而領域層再根據子領域的情況按照開閉原則進行垂直拓展。
架構探索
通過以上分析，如果我們嘗試將馮諾依曼的設計模式上移到業務系統，，讓我們的系統職責和業務角色收斂關係更清晰，同時保證業務子系統做到儘可能唯讀，如果有新的業務我們去分化重開系統；
我們可以嘗試用星鏈來實現業務作業系統，梳理各業務系統的職責，梳理出穩定系統，周邊業務系統，以及公共功能系統，並且可以將比較穩定的業務系統進行產品化。去嘗試探索一種新的商業模式。
另外，其實咱們在推行ddd的過程中，通常會比較嚴格的按照戰略戰術的模式，重建領域模型，但是在實際生產中，我們的很多老系統都揹負很重的業務量，輕易重構資料結構，風險會非常大，其實我們可以嘗試按照開閉原則，先試圖對老系統進行分化出新的系統，將系統的api進行收斂到同一個領域內，等這第一步完成後，可以在考慮在當前領域內實現領域模型的梳理。
或許這可能是開閉原則下比較理想的架構模式，複用京東bigboss文化的宣傳語：
積木式組織—探索未來式，人人是boss;
積木式系統—探索未來式, 職責要清晰；
而積木式系統，必然是比較整潔的系統了，自然當關注某一個模組的業務的時候，就只需要將認知主要集中在當前模組即可。而對於一些重複通用的功能，研發可能甚至只需要關注輸入和輸出即可，這樣相當於通過職責的抽象將對應的能力打造成了能力光環，只要涉及到相關的研發的同事，天然就具有了這方面的能力。
擴充套件思考
在我們的業務系統中，常常通過非同步訊息來實現通訊的處理，可能會存在一種方式，就是將我們的mq的監聽和業務處理混合在一起，當mq的監聽比較少的時候，或許系統還算整潔；但當我們的系統監聽非常多的時候，這個系統似乎就成了大雜燴了，什麼業務都可能會有。這樣導致這個系統的職責非常的不清晰。
而業務監聽本來就應只是一個系統的共用功能，是可以將其抽象為平臺功能，所以按照以上開閉原則設計，我們提供監聽後對應業務的處理介面，在監聽之後自動呼叫介面即可。該系統只負責做mq監聽的處理。系統角色草圖如下：
寫在最後
在我們生活中，發現問題的時候，大部分人只是看到了當前現象，而少數人看到了這個現象背後的原因，而只有極少數的人能全面看到這個現象的底層根源，從全域性的視角尋找解決方案。而第三者應該是我們追求的一種境界，這應該是工程師文化/工匠文化的體現所在。此所謂：
眾生畏果，菩薩畏因，佛畏系統