如何設計分層架構和交互接口 API?

2020-12-05 計算機java編程

今天我們繼續來聊聊分層架構的設計流程,以及接口設計方法等內容。通常,我們可以將分層架構的設計流程分解為下列 4 個步驟:

第一步,結合現實情況,將系統劃分成多個層次。第二步,確定層與層之間的關係,梳理出層與層之間的交互接口。第三步,將功能相近的接口劃歸到一個模塊,確保模塊高內聚,對外低耦合。第四步,在此基礎上進一步明晰接口的參數列表。僅僅四個步驟就完成了架構設計嗎?這會不會太簡單空洞了呢?各位看官,不要著急,請聽蔡老師慢慢道來,每個步驟都有極具可操作性的方法及工具。

層次的切分方法

面對一個龐然大物,你該如何下手呢?不用擔心,這已經給你準備了庖丁解牛的方法,輕輕鬆鬆把一個複雜的大系統變得可以掌控了。

第一刀:按照這套方法論來進行架構設計,最理想的情況是將X軸切分成七層。而第一刀應該先切在業務和領域之間,即通過API把兩邊解耦。交互和業務跟用戶關聯度高,經常隨需求變化而改動,而領域和資源相對比較穩定。第二刀:考慮到要完成某些業務功能,系統可能需要調用外部系統協同完成,為了保證領域層相對穩定,我們需要隔離外部系統或數據持久層變化帶來的影響,那第二刀應該切在領域和資源之間。第三刀:考慮到同樣的一個業務可能會有多套界面,例如有Web版、桌面版、移動版等,為了提高重用,隔離變更,那接下來要把交互和業務切開。通過上面這「溫柔的三刀,我們就可以把一個大塊頭切分成七個層次。

接口的設計方法

在確定分層之後,我們可以把每個業務需求的交互時序圖畫出來,而分層就是交互時序圖的主角。這時候我們就可以清晰地找出層與層之間的交互接口,以及可以初步確定每個接口的參數列表。

考慮到API、領域模型接口、SPI是最為關鍵的接口,那良好的設計就顯得更為重要。那如何能夠設計出良好的接口呢?在這點上,蔡老師也有非常豐富的經驗可以分享:

找出領域對象:通過多輪領域訪談,與業務專家一起分析出領域對象。另外,也可以通過研究外部接口及數據字典來明晰領域對象,反過來也可以豐富外部接口和數據字典。設計領域模型、資源模型、數據模型:在挖掘領域對象的過程中,我們就可以開始設計領域模型了,確定領域對象之間的關聯關係。當關聯關係逐步清晰之後,我們還可以根據關聯關係的密集程度對領域對象的組織方式做一些調整,找出核心的領域對象集合,其他領域對象可以歸類到圍繞核心領域對象集合的衛星集合裡面。通過多輪調整,我們可以得到一個能夠映射業務、關係簡化的領域模型。然後兵分兩路啟動資源模型和數據模型的設計工作。上述三個模型之間的關係及區別,請參見下文。設計領域模型接口、APISPI、資料庫:在設計領域模型接口時,我們要儘量做到不多不少,這些接口都是對外提供服務所必須的,也是全面的,並且粒度要細。在設計API時,我們要考慮內外客戶的需求和特點,做到方便易用,可以參考RESTful API設計相關的資料。在設計SPI時,我們要儘量隔離資源層對領域層的影響。在完成上述工作之後,我們就可以進入實施階段,開始啟動代理層、核心層和服務層的代碼設計工作。另外,如果是對線上已有系統進行升級,那還要開始制定數據的遷移計劃。

三個模型之間的關係及區別

領域模型,映射特定業務領域當中核心領域對象及其關聯關係,這些對象及關係的存在都是完成業務規則所必須的,甚至是法律法規等明文要求的,不會輕易變動。資源模型,基於領域模型,從為內外客戶提供服務的角度分析定義出來的,包含了資源對象及其關聯關係。根據內外客戶的特點及需求,我們可以調整資源模型中的內容。數據模型,基於領域模型,從存儲(持久化或緩存)信息的角度分析定義出來的,包含數據對象及其關聯關係。根據存儲載體的特點及需求,我們可以調整數據模型中的內容。先分享到這裡,堅持原創不易,如果你覺得有價值,麻煩動動手指點個 「」,「計算機java編程」會更有動力。另外,我還會持續分享職業規劃、應聘面試、技能提升、影響力打造等經驗,關注計算機java編程 」,賦能程序人生

相關焦點

  • 理解RESTful API 架構設計規範與實踐
    摘要本文介紹了 REST 的由來,對 REST 的風格架構設計指導原則做了詳細的說明。同時舉例了過往開發中若干細節的考慮和實現方案。文字略長,預計需要10 ~ 20 分鐘讀完。也可以收藏起來,在需要的時候查閱。RESTful 架構是目前流行的一種網際網路應用架構。
  • 如何設計restful風格接口
    restful風格接口URL定位資源,用HTTP動詞(GET,POST,DELETE,DETC)描述操作。識別(identify)、 表示(represent) 、交互(interact with)。看Url就知道要什麼看http method就知道幹什麼看http status code就知道結果如何1.
  • 架構師該如何為應用選擇合適的API
    前言:架構師的主要活動是做出正確的技術決策。選擇合適的API是一項重要的技術決策。那麼今天就看看API的選擇問題。應用程式編程接口(API)是一種計算接口,它定義了多個軟體中介之間的交互。它定義了可以進行的調用或請求的類型,如何進行調用,應使用的數據格式,遵循的約定等。它還可以提供擴展機制,以便用戶可以以各種方式擴展現有功能。在不同程度上。
  • 如何設計高效PL和PS數據交互通路的AXI接口
    如何設計高效PL和PS數據交互通路的AXI接口 肅寧老趙 發表於 2020-11-13 16:43:47 (一)AXI接口
  • 架構設計:業務邏輯和技術分離
    例如,阿里巴巴在沒有中臺部門之前,每個業務部門的技術架構都是煙囪式的,淘寶、天貓、飛豬、1688 等各有一套體系結構。而後,成立了共享平臺事業部,打通了帳號、商品、訂單等體系,讓商業基礎實施的復用成為可能。 應用架構:由應用架構師負責,他需要根據業務場景的需要,設計應用的層次結構,制定應用規範、定義接口和數據交互協議等。
  • 這後端API接口寫得才叫一個優雅!網友直呼:666
    因為老顧這篇主要介紹的是API接口,所以我們聚焦點,其他的模塊小夥伴們自行去補充。 接口交互 前端和後端進行交互,前端按照約定請求URL路徑,並傳入相關參數,後端伺服器接收請求,進行業務處理,返回數據給前端。
  • 什麼才是真正的架構設計?
    部署拓撲架構圖(實際物理架構圖):拓撲架構,包括架構部署了幾個節點,節點之間的關係,伺服器的高可用,網路接口和協議等,決定了應用如何運行,運行的性能,可維護性,可擴展性,是所有架構的基礎。這個圖主要是運維工程師主要關注的對象。物理架構主要考慮硬體選擇和拓撲結構,軟體到硬體的映射,軟硬體的相互影響。三.
  • Restful Api-接口設計
    RESTful API特徵 (1) 每一個uri代表一種資源; (2) 客戶端和伺服器之間,傳遞這種資源的某種表現層; (3) 客戶端通過四個HTTP動詞(GET (4) URL中通常不出現動詞,只有名詞 (5) 使用JSON不使用XML設計方式 HEAD(SELECT)只獲取某個資源的頭部信息 GET(SELECT)獲取資源 POST(CREATE)創建資源 PATCH(UPDATE)更新資源的部分屬性(很少用,一般用POST
  • 硬體與軟體接口如何與CPU交互
    硬體/軟體接口(簡稱為"HSI")是一個術語,用來描述SoC外圍設備的配置和功能,以及它們如何與CPU交互。 從寄存器位到訪問類型、屬性和功能的各種因素的數量,在現代SoC中可能是絕對令人吃驚的。 例如,如果有一個32位地址總線,可以訪問2 ^ 32內存映射寄存器。
  • 4種主流API架構風格對比
    本文主要討論了四種 API 架構的風格,闡述了各自的優缺點,並介紹了每種API架構適合的情況。兩個單獨的應用程式需要中介程序才能相互通信。因此,開發人員經常需要搭建橋梁——也就是應用程式編程接口(API),來允許一個系統訪問另一個系統的信息或功能。
  • 詳解API網關核心功能和API管理擴展
    在傳統的ESB總線進行服務集成的時候我們就經常談到一個概念就是位置透明,即需要屏蔽底層業務模塊提供API接口服務地址信息,並實現多個微服務API接口的統一出口。即類似設計模式裡面經常談到的門面模式。如何給API網關一個定義?
  • 從企業架構到信息化規劃,從現狀調研到架構設計的核心邏輯
    應用架構規劃需要體現逐層展開的核心思路,總體應用架構清楚後將細化到第二個層次:功能架構和集成架構。這個時候細化相當重要,真正解決業務目標和業務功能的落地問題。功能架構包括功能模塊和具體核心功能點,這些梳理出來後我們需要明確當初提到的業務架構和業務需求在功能架構中如何落地。其次,以某個應用為核心,來觀察該應用和外部應用間的集成關係以及集成後如何協同。前者為功能性需求,後者為接口需求。
  • 4種主流的API架構風格對比
    因此,開發人員經常需要搭建橋梁——也就是應用程式編程接口(API),來允許一個系統訪問另一個系統的信息或功能。  為了快速、大規模地集成不同的應用程式,API 使用協議或規範來定義那些通過網絡傳輸的消息的語義和信息。這些規範構成了 API 的體系結構。  在過去,人們已經發布了多種不同的 API 架構風格。每個架構風格都有它獨有的標準化數據交換的模式。
  • 你的數據倉庫既要有「維度模型設計」也要看「分層架構」
    維度模型設計和分層架構都是數據倉庫必不可缺的。維度建模以分析決策的需求出發構建模型,構建的數據模型為分析需求服務,因此它重點解決用戶如何更快速完成分析需求,同時還有較好的大規模複雜查詢的響應性能。而分層架構的設計的主要是為在管理數據的時候,能對數據有一個更加清晰的掌控。這篇乾貨將帶你認清數據倉庫「維度模型設計」與「分層架構」。
  • 利用yii2和swagger打造完美的RestFul Api接口
    技術人員照著此文,可以直接搭建一個yii2和swagger結合的RestFul風格的API接口平臺!接口的目的就是return回信息的,我們需要配置返回信息的格式默認都是json格式。第四步:建立swagger的入口文件和信息文件我們在項目的controllers目錄下新建一個與默認的SiteController.php同級的SwaggerControll.php文件swagger還需要一個配置文件,才能保證在讀取信息時,不出錯。因為,上圖中,我們只讓swagger到v1下面的controllers下面去掃描。
  • 數據倉庫系統架構和數倉分層體系介紹
    一、數據倉庫體系架構 公司藉助的第三方數據平臺,在此平臺之上建設數據倉庫。因為第三方平臺集成了很多東西,所以省去了不少功夫。 數據倉庫的體系架構,無外乎就是數據源、數據採集方式、計算存儲系統、數據應用層,這幾個方面。
  • 架構師必須知道的架構設計原則
    這些原則沉澱在架構師的腦海中,最終內化成他的 mindset,以潛意識方式影響和指導他的架構和設計工作。 一晃我在軟體研發行業工作十多個年頭了,前面大部分時間做架構設計和開發,現在轉型做研發管理。隨著時間的推移,很多技戰術細節性的東西 (工具,框架,程式語言) 在我腦海中漸漸模糊,但是一些平時學習積累起來,並且在實踐中加深體會的軟體架構設計和組織原則,這些原則性的東西卻絲毫沒有被時間衝淡,反而愈加清新。現在即使我不在一線開發,但這些沉澱下來的原則仍然潛移默化地影響我的日常管理和部分架構設計指導工作。我想有必要總結一下那些業界知名,給我留下深刻印象的軟體架構設計和組織原則,和大家一起分享。
  • 解讀交互稿模板:如何讓設計稿更規範化?
    PS:本文適用於移動端,Axure軟體製作的文檔型交互稿。交互稿應該包含哪些內容?如何搭建一個合理的交互稿結構?各個界面應該如何擺放?清晰易讀的設計說明應該是怎樣的?想必作為一個新人,很難完全弄清上面的問題。
  • 分享幾個在線生成網址二維碼的API接口
    想要實現這樣的功能其實很簡單,下面麥布分享幾個在線生成網址二維碼的API接口。都是採用http協議接口,無需下載安裝什麼軟體,可簡單方便地引用,這才是最簡單、最便捷的免費網址二維碼生成工具。url=http://www.54admin.net        4.http://qr.liantu.com/api.php?