主頁 > 軟體設計 > 借降本增效之名,探索開閉原則架構設計

借降本增效之名,探索開閉原則架構設計

2023-04-05 14:36:29 軟體設計

作者:京東科技 胡燦海

引語

在我們的研發生產活動中,經常會遇到如下類似的疑惑:

  1. 業務和技術在公司組織活動中,究竟應該各扮演什么樣的角色?

  2. 技術的目的是什么?

  3. 研發生產活動中,如何提高生產事故發生的下限?

  4. 如何充分提高isv或者外協人員價值最大化?

  5. 《人月神話》說優秀程式員是普通程式員研發效率10倍,如何可以提高研發效率水位線呢?

  6. 如何避免《人月神話》指出的“焦油坑”?

  7. 如何更好的對老系統進行ddd升級?

這些疑惑單獨看都可以有很多的解決思路,或者從制度層面解決,或者從技術層面解決,或者業務層面解決,等等,甚至也有可能出現某些解決思路按下葫蘆浮起瓢,但如果將這些問題統一起來看,是否能找到他們對應的共性,嘗試從最底層的邏輯找到問題解決的切入點呢?

疫情啟發

新冠疫情持續了三年時間,讓咱們的生活發生了很多與之前不一樣的改變,比較典型的一個現象就是我們在公共場所的椅子上會要求進行隔位相坐,經過長期的觀察,發現很多場所這樣的要求和提示如同虛設,我們不討論政治和經濟,單純從實作設計的維度來思考如何讓這個要求能落到實處,實實在在的幫助我們更好的進行科學防疫,以下是幾個場合的隔位相坐實作方式:

image.png

我們拒絕紅燈思維,認為每種實作方式在那時那情那景下都是最優選擇,從這四個實作方式中,我們可以發現從效果和美觀上來看,是可以認為存在一個遞進的關系,極其類似我們的系統的演化程序,假設衛健委給出行政要求,公共場合必須要將隔位相坐落到實處,或許能有人挖掘出一種商業模式,即提供隔位相坐最優解決方案的能力和服務,從中賺取服務費用,畢竟不是每個目標主體都能在當時情景能實作最佳,或者需要更大成本才能實作較佳,

系統實作反思

  1. 為了得到高質量的軟體產品,我們是應該把精力更多地集中在提升其中每一個人員、程序、產出物的能力和質量上,還是該把更多精力放在整體流程和架構上?—— 《鳳凰架構》

  2. 系統的行為價值 和 架構價值 到底哪個更重要?——《架構整潔之道》

  3. 系統是演化發展的,根據疫情隔位相坐實作方式的啟發,系統是否可以以巨人肩膀為起點開始演化發展?

對于以上反思,下面嘗試從一種切面來和大家一起探討,

統一溝通語言

有很多的方案的討論最終達不成一致,很大程度在于雙方溝通語言不統一,即雙方討論問題最基本的基石基礎并不是一致的,所以怎么討論都不可能達到一致的結論和目標,所以我們首先統一一下溝通語言,

我們知道,咱們作為一個商業公司,最底層的邏輯肯定是商業盈利,那么我們作為其中的一員,我們每個人有以下三個角色(注:以程式員崗位進行分析),每個角色的職責價值嘗試做如下決議:

image.png

個人角色

曾有企業家有言:一個企業的邊界取決于其創始人的認知邊界,其實對個人也是如此,一個人的價值大小也是由其認知邊界決定的,個人角色短期來看,對咱們解決方案討論意義并不是那么重要,這個也不是能很快改變的,暫且忽略影響,

公司職員角色

員工的任何公司任何活動都應該朝著有利于公司市場競爭優勢的方向進行的,甚至可能還關注公司第二曲線,在我們公司文化里面還倡導第三曲線;

程式員角色

我們認為技術的最終目的更應該是降本增效,具體體現為業務初創期低成本快速迭代,業務成長期快速低成本規模化,以及將以上低成本能力抽象成能力光環,從而實作助力業務快速迭代,以及釋放創造力助力管理,

兩個概念

回到本文主題,本文主要是嘗試通過探索開閉原則架構設計來實作降低認知負載,從而達到降本增效的目的,因為在研發活動中,我們的關注點越發散,會越容易降低我們的研發效率,所以本文的目的是想通過系統遵循開閉原則架構進行設計,保證系統的職責的清晰和單一化,以收斂研發的關注,保證程式員能集中精力將事情做好,主要從加強系統純潔度維度來嘗試進行闡釋,

image.png

開閉原則,耳熟能詳的原則,其比較關鍵的特點在于,系統或者模塊的只讀性,以及和 職責單一原則的一體兩面;如此在我們的研發活動程序中,可以將穩定的需求和 常變的需求,通過組合的方式將不同的模塊進行擴展,而穩定的需求我們其實是可以進行產品化封裝的,

鳳凰架構的邏輯

鳳凰架構的思想是參考生命系統的可靠性和穩定性,希望通過一系列不穩定的子系統來打造一個穩定可靠的大系統;而其實生命系統的可靠性也不是一蹴而就的,并且也只是一個穩定且發展的文明系統的載體;這個文明系統的演化程序非常類似咱們需求交付的程序;

image.png

通常比較主流的觀點對于文明的演化理論是進化論,進化論來源于達爾文的《物種起源》的進化樹,而進化論其實存在未能解釋的空缺,即為什么進化樹是由單細胞向多細胞進化和低等生物向高等生物進化而不是相反,以及進化與熵增定律和質能方程E=mc2沖突,即進化來源于什么?有學者提出一套演化理論即“遞弱代償”理論(不討論其爭議性,只分析客觀邏輯),解釋了以上空缺,即從30億年前單細胞到軟體生物到脊柱生物到人類,物種伴隨的文明越發達,而物種的存在度空間會越小,因為單細胞是全能的,從吸收到排泄,以及繁殖都能實作,而人類的組織,已不再是單細胞而是多細胞高度分化成不同功能的獨立的組織,而某個組織也只有某個功能,放棄了單細胞其他大部分的功能,因此隨著文明的愈發達,而文明當前的載體分化程度越高以至于產生了新的物種,而分化的程度越高,誕生出來的新物種的存在度會越低,如同上圖右公式圖,即物種的存在度與系統的文明發達程度成遞弱關系,(參考《物演通論》)

這極其類似我們需求交付程序,即單個系統不再是萬能的,而是分化成不同的小型子系統,而通過每個系統繼續高度的分化和升級,使得整個大系統的能力越來越豐富和強大,

而我們的系統分化的原則就應該是上述的開閉原則和單一職責原則,這才能保證每個系統能獨立的分化和演進,保證了在需求迭代的程序中,整個系統可以不斷的進化為新的業務物種形態,并且進化程序中依然可靠,

在一個系統內,進化的本質是替換部分組件使之成為新的物種,而不是當前物種的升級;而系統最終升級演化的趨勢就是系統內所有組件都能敏捷替換,修改一下路由,很低成本替換組件,這樣優化系統的成本會越來越低,

軟體系統的邏輯

image.png

我們再來分析咱們軟體系統的結構,主要分兩部分,一部分是基礎設施,一部分是業務部分;而基礎設施主要是馮諾依曼體系;而在討論開閉原則時,最典型的案例就是馮諾依曼體系;
馮諾依曼體系可以簡化為cpu,存盤,輸入輸出;正是這套擴展性非常強的體系支撐著在計算機世界的發展,cpu通過元指令和指令流的分離,資料與計算的分離,并且提供中斷回呼,來落地了開閉原則,保證了多么復雜的需求的實作都不再需要修改cpu了;而將變化的業務交給輸入輸出;上面的作業系統則將馮諾依曼體系進行了封裝,提供了方便的操作方式,

試想:能否將上層的頁面模式的設計思路也復用底層的基礎設施的設計思路呢?在最外層再提供一層“作業系統”提供使用呢?

再反觀現在行業的各種服務化,SAAS,PAAS,IAAS 其實也就是這種思路的體現和落地,

星鏈的邏輯

image.png

貨指的是一些業務側和中臺側的能力,中臺側能力如商品、支付、風險等,業務側能力如賬戶、交易、賬務等,

人包括各類角色,如消費者側的預授信用戶、運營側的推廣人員、商戶側的結算人員等,

場是人與貨發生互動的場所和方式,人可能通過各類介質如金融APP、商城APP、小程式、H5等與貨互動,通過各類產品與貨互動,通過各類運營方式、不同流量來源來與貨互動,

貨是相對穩定的,一般不是面向特定人和場的,是沉淀的業務和中臺能力,構建貨的能力,消金內部借鑒的是領域驅動設計(DDD)和中臺化的思想,這些能力沉淀下來的是相對穩定的、與場景關系不大的領域原子微服務,

而這個思想不正是開閉原則的另一種表達么?

業務垂直拓展思考

image.png

這是對不同復雜度的系統的一個簡單概括總結,我們的系統可能處于高級別分布式系統的層次,那我們再思考一下我們的業務系統,我們進行垂直拓展的顆粒度能達到什么級別呢?

image.png

從通常ddd的分層的思路來看,我們可以嘗試將系統將應用層,不同場景的聚合中偏客戶端的模塊交給 上層接入層,是否可以將接入層單獨抽離成獨立系統,比如交給星鏈來實作(如果不用星鏈可能會比較重),以保證了領域與接入層的相互獨立,而領域層再根據子領域的情況按照開閉原則進行垂直拓展,

架構探索

image.png

通過以上分析,如果我們嘗試將馮諾依曼的設計模式上移到業務系統,,讓我們的系統職責和業務角色收斂關系更清晰,同時保證業務子系統做到盡可能只讀,如果有新的業務我們去分化重開系統;

我們可以嘗試用星鏈來實作業務作業系統,梳理各業務系統的職責,梳理出穩定系統,周邊業務系統,以及公共功能系統,并且可以將比較穩定的業務系統進行產品化,去嘗試探索一種新的商業模式,

另外,其實咱們在推行ddd的程序中,通常會比較嚴格的按照戰略戰術的模式,重建領域模型,但是在實際生產中,我們的很多老系統都背負很重的業務量,輕易重構資料結構,風隙訓非常大,其實我們可以嘗試按照開閉原則,先試圖對老系統進行分化出新的系統,將系統的api進行收斂到同一個領域內,等這第一步完成后,可以在考慮在當前領域內實作領域模型的梳理,

或許這可能是開閉原則下比較理想的架構模式,復用京東bigboss文化的宣傳語:

積木式組織—探索未來式,人人是boss;
積木式系統—探索未來式, 職責要清晰;

而積木式系統,必然是比較整潔的系統了,自然當關注某一個模塊的業務的時候,就只需要將認知主要集中在當前模塊即可,而對于一些重復通用的功能,研發可能甚至只需要關注輸入和輸出即可,這樣相當于通過職責的抽象將對應的能力打造成了能力光環,只要涉及到相關的研發的同事,天然就具有了這方面的能力,

擴展思考

在我們的業務系統中,常常通過異步訊息來實作通信的處理,可能會存在一種方式,就是將我們的mq的監聽和業務處理混合在一起,當mq的監聽比較少的時候,或許系統還算整潔;但當我們的系統監聽非常多的時候,這個系統似乎就成了大雜燴了,什么業務都可能會有,這樣導致這個系統的職責非常的不清晰,
而業務監聽本來就應只是一個系統的共用功能,是可以將其抽象為平臺功能,所以按照以上開閉原則設計,我們提供監聽后對應業務的處理介面,在監聽之后自動呼叫介面即可,該系統只負責做mq監聽的處理,系統角色草圖如下:
image.png

寫在最后

在我們生活中,發現問題的時候,大部分人只是看到了當前現象,而少數人看到了這個現象背后的原因,而只有極少數的人能全面看到這個現象的底層根源,從全域的視角尋找解決方案,而第三者應該是我們追求的一種境界,這應該是工程師文化/工匠文化的體現所在,此所謂:

眾生畏果,菩薩畏因,佛畏系統

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/549183.html

標籤:其他

上一篇:9款日志采集&管理工具對比,選型必備!

下一篇:【裝飾器設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more