Skip to content
Read this post in: de_DEen_USes_ESfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW
Home » TOGAF » TOGAF ADM:十大技術——第三部分:架構模式

TOGAF ADM:十大技術——第三部分:架構模式

在企業架構領域中,架構模式是解決常見問題的有效方案的重要工具。模式能夠將構建模塊置於具體情境中,並為架構師提供過去已被證明有效的解決方案設計藍圖。本文將探討 TOGAF ADM 框架下的架構模式概念,並提供一個在業務應用開發情境中的架構模式範例。

什麼是架構模式

「模式」被定義為:「一個在某一實際情境中曾具備實用性的想法,且很可能在其他情境中也具備實用性」(來源:《分析模式——可重用的物件模型》,M. Fowler 著)。

在 TOGAF 標準中,模式被視為將構建模塊置於具體情境中的方式;例如,用以描述可重用的問題解決方案。構建模塊是您所使用的工具:模式可以告訴您如何使用它們、何時使用、為何使用,以及在使用過程中需要做出哪些權衡。

模式承諾能協助架構師識別過去已被證明能有效解決問題的架構與/或解決方案構建模塊(ABB/SBB)組合,並可能為未來的有效解決方案奠定基礎。

模式技術普遍被認為是由建築師克里斯多福·亞歷山大所建立的一種具有價值的架構設計方法,他在1979年出版的《永恆的建築之道》一書中描述了這種方法。該書介紹了模式應用背後的理念,亞歷山大隨後又出版了兩本進一步著作(《模式語言》與《俄勒岡實驗》),進一步闡述了模式方法在架構中的特點與優勢。

TOGAF ADM 中的架構模式

架構開發方法(ADM)是開放集團 TOGAF 標準的核心組成部分,提供了一個創建與管理企業架構的框架。在 ADM 中,架構模式是一種強大的工具,可協助架構師識別已被驗證的常見問題解決方案,並加速有效架構的開發。

從本質上講,架構模式僅是對一個已被實踐證明有效的可重用問題解決方案的描述。正如上述定義所示,模式是一種在某一情境中曾具備實用性的想法,且很可能在其他情境中也具備實用性。模式可用於描述不同抽象層級的解決方案,從描述系統整體結構的高階架構模式,到描述單個組件應如何實現的低階設計模式。

使用架構模式的主要優勢之一在於,它能協助架構師識別過去已被證明能有效解決問題的架構構建模塊(ABB)或解決方案構建模塊(SBB)組合。這可以節省時間與精力,因為它為架構開發提供了起點,而非每次新專案都從零開始。

此外,架構模式有助於確保架構的一致性與整體性。透過使用模式來描述常見問題的解決方案,架構師可以建立組織內通用的語言與概念體系。這有助於避免誤解,並確保所有人朝著共同的架構願景努力。

模式技術已被建築師克里斯多福·亞歷山大確立為一種具有價值的架構設計方法,他在《永恆的建築之道》一書中描述了這種方法。亞歷山大的理念後來在另外兩本著作《模式語言》與《俄勒岡實驗》中進一步拓展。

在企業架構的背景下,可使用多種不同類型的架構模式。其中最常見的包括:

  1. 參考架構——描述系統或應用的整體結構,並為架構開發提供起點。
  2. 解決方案模式——描述如何透過 ABB 與 SBB 的組合來解決特定問題。
  3. 流程模式——描述架構開發與實施的最佳實務與常見工作流程。
  4. 設計模式——描述單個組件應如何設計與實現,有助於確保架構中的一致性與可維護性。

架構模式是架構師開發有效且高效企業架構的強大工具。透過識別已被驗證的常見問題解決方案,架構師可在節省時間與精力的同時,確保架構的一致性、整體性,並與組織的目標與宗旨保持一致。

架構模式文件編寫範本

1. 模式名稱

模式的描述性名稱,應能清楚傳達所解決的問題。

2. 問題

對模式所要解決的問題或挑戰的描述。應清晰且具體,並提供模式的背景情境。

3. 情境

對模式預期使用情境的描述。應包含組織資訊、正在開發的系統或應用,以及任何相關的限制或約束。

4. 解決方案

對模式所提供的解決方案的描述。應清晰且具體,並說明如何運用該模式來解決第二部分所述的問題。

5. 優勢

對使用該模式優勢的描述。應說明該模式如何有助於解決問題,並提供支持其有效性的證據。

6. 取捨

描述在使用此模式時必須做出的任何取捨或妥協。這應包括該模式的任何限制或缺點,以及必須管理的任何風險。

7. 實施

描述如何實施該模式。這應包括應用該模式的指導建議,以及任何相關的範例或使用情境。

8. 相關模式

列出可能與當前模式配合使用的相關模式。這應包括任何密切相關的模式,或可與當前模式結合使用的模式。

9. 參考資料

列出在開發該模式時使用的參考資料和來源。這應包括任何相關的出版物、文章或其他資源。

透過使用此範本,架構師可以建立清晰且有效的架構模式,以便在不同專案和情境中輕鬆共享與重複使用。

商業情境下架構模式的範例

讓我們考慮一個在商業應用程式開發情境下的架構模式範例。

假設一家公司需要開發一個新的基於網路的應用程式來管理客戶關係。他們面臨的主要挑戰之一是如何確保該應用程式具備可擴展性,並能處理大量同時使用者。

 

使用上述所列的架構模式範本,我們可以建立一個模式來解決此問題:

1. 模式名稱:可擴展的網路應用程式

2. 問題:開發一個可處理大量同時使用者的基於網路的客戶關係管理應用程式。

3. 情境:一家公司需要開發一個新的基於網路的應用程式來管理客戶關係。該應用程式將由大量使用者存取,且必須具備可擴展性以應對使用高峰。

4. 解決方案:可擴展的網路應用程式模式提供了一種開發可處理大量同時使用者的基於網路應用程式的解決方案。該模式的主要要素包括:

  • 負載平衡:將進來的請求分散到多個伺服器,以確保單一伺服器不會過載。
  • 快取:使用記憶體快取來儲存經常存取的資料,以減少資料庫的負載。
  • 水平擴展:在基礎設施中增加額外的伺服器,以應對增加的負載。
  • 資料庫分片:將資料庫分割成較小的區塊,以將負載分散到多個伺服器。

5. 優點:透過使用可擴展的網路應用程式模式,公司可以確保其應用程式能處理大量同時使用者,而不會出現效能問題或停機。這可以透過確保應用程式始終可用來提升客戶滿意度並增加收入。

6. 取捨:可擴展的網路應用程式模式需要額外的基礎設施和資源來實施,這可能會增加成本。此外,實作負載平衡和快取可能會增加應用程式架構的複雜性。

7. 實施: 為實現可擴展的Web應用程式模式,公司應考慮使用負載均衡器(例如NGINX),利用Redis或Memcached等技術實現快取,並透過AWS或Azure等雲端平台進行水平擴展。資料庫分片可使用MongoDB等資料庫技術來實現。

8. 相關模式:與可擴展Web應用程式模式結合可能有用的相關模式包括:

  • 微服務架構:將應用程式拆分成更小、更易管理的服務,這些服務可獨立擴展。
  • API閘道:提供單一入口點以存取應用程式的服務並管理流量。

9. 參考資料:在開發可擴展Web應用程式模式時可能有用的參考資料包括:

  • High Scalability(部落格):
  • 《建構可擴展的Web網站》(書籍),作者:Cal Henderson

透過使用此架構模式,公司可在開發用於管理客戶關係的可擴展Web應用程式時節省時間與精力。該模式提供了一個經過驗證的解決方案,以應對常見問題,且可輕易調整以符合公司的特定需求與限制。

單一登入情境下的架構模式範例

以下是在單一登入(SSO)情境下的架構模式範例:

Two Factor Multi-Factor Authentication Security Concept

1. 模式名稱:單一登入(SSO)

2. 問題:組織內的多個應用程式要求使用者分別進行驗證,導致使用者體驗不佳,並增加管理使用者帳戶的行政負擔。

3. 背景:一個組織擁有數個需要使用者分別驗證的應用程式,導致使用者感到煩躁與困惑。該組織希望透過允許使用者一次驗證即可存取所有應用程式,無需重複輸入憑證,來提供無縫的使用者體驗。

4. 解決方案:單一登入模式提供了一種解決方案,讓使用者只需驗證一次即可存取多個應用程式,無需重複輸入憑證。該模式的主要要素包括:

  • 身分識別提供者(IdP):一個中央化服務,負責驗證使用者,並提供可被用於存取其他應用程式的權杖或驗證資訊。
  • 服務提供者(SP):一個依賴IdP驗證使用者的應用程式或服務,並根據IdP提供的權杖或驗證資訊來提供存取權限。
  • 標準協定:使用SAML、OAuth或OpenID Connect等產業標準協定,以實現IdP與SP之間的通訊。

5. 優點:透過使用單一登入模式,組織可提供無縫的使用者體驗,並降低管理使用者帳戶的行政負擔。使用者只需驗證一次,即可存取所有應用程式,無需記住多組憑證。這可提升使用者滿意度,並降低支援中心的支援成本。

6. 優缺點:實施單一登入模式需要額外的基礎設施與資源,可能導致成本增加。此外,與現有應用程式整合可能需要客製化開發或設定,這會增加複雜性。

7. 實施方式: 為實現單一登入模式,組織應選擇支援業界標準協定(如 SAML、OAuth 或 OpenID Connect)的身份提供者。服務提供者應設定為依賴身份提供者進行驗證與授權。現有的應用程式可能需要與身份提供者整合,這可能需要客製化開發或設定。

8. 相關模式:與單一登入模式結合可能有用的相關模式包括:

  • 聯邦身份:將單一登入模式擴展至支援跨組織或領域的驗證。
  • 基於屬性的存取控制:利用身份提供者提供的使用者屬性來控制應用程式內資源的存取。

9. 參考資料:在發展單一登入模式時可能有用的參考資料包括:

透過使用此架構模式,組織可透過實施單一登入解決方案,讓使用者在不需重複輸入憑證的情況下存取多個應用程式,從而改善使用者體驗並降低管理負擔。此模式提供了一個經過驗證的解決方案,以應對常見問題,且可輕易調整以符合組織的特定需求與限制。

企業架構模式與軟體架構模式

企業架構模式與軟體架構模式雖有關聯,但屬不同概念。

軟體架構模式專注於單一軟體系統或應用程式的設計與實作。它們提供一組指導原則與最佳實務,用於設計與實作系統的軟體組件,例如模組、介面與互動。

另一方面,企業架構模式專注於組織內多個軟體系統與應用程式的設計與對齊。它們提供一組指導原則與最佳實務,用於設計與實作企業的整體架構,包括其業務流程、資料結構與技術基礎設施。

企業架構模式通常處理系統整合、互操作性與可擴展性等議題,這些通常不在軟體架構模式的涵蓋範圍內。它們也考慮軟體系統部署的更廣泛商業背景,並致力於使資訊系統與組織的目標與宗旨保持一致。

企業架構模式的範例包括服務導向架構(SOA)、業務流程管理(BPM)與企業整合模式(EIP),而軟體架構模式的範例則包括模型-檢視器-控制器(MVC)、微服務與分層架構。

軟體架構模式

軟體架構模式是軟體設計中常見問題的可重用解決方案。它們透過定義一組規則與指導原則,提供一種結構化的方法來設計與實作軟體系統,以確保系統具備強健性、可擴展性與可維護性。

軟體架構模式提供系統的高階視圖,識別其關鍵組件及其互動方式。它們定義這些組件之間的關係,並提供一組規則,說明它們應如何通訊與協作。

透過使用軟體架構模式,開發人員可藉由重用經過驗證的常見問題解決方案,避免每次新專案都從零開始,從而節省時間與精力。這有助於提升最終軟體的品質,同時減少開發時間與成本。

軟體架構模式的一些範例包括模型-檢視器-控制器(MVC)、微服務、分層架構、服務導向架構(SOA)與事件驅動架構(EDA)。

以下是一些常見的軟體架構模式:

  1. 模型-檢視器-控制器(MVC)模式:此模式將應用程式分為三個相互關聯的組件——模型、檢視器與控制器——以協助管理複雜性並實現關注點分離。
  2. 微服務架構:此模式將應用程式拆解為較小的、可獨立部署的服務,這些服務可分別進行開發、部署與擴展。
  3. 分層架構:此模式將應用程式劃分為邏輯層,每一層負責應用程式功能的特定方面,以提供模組化與關注點分離。
  4. 服務導向架構(SOA):此模式是一種建立分散式系統的架構方法,以服務作為基本的構建單元。
  5. 事件驅動架構 (EDA):此模式強調系統內發生事件的產生、檢測、消費和回應,從而實現更具彈性和可擴展性的架構。
  6. 領域驅動設計 (DDD):此模式鼓勵使用一種通用語言和模型來描述問題的領域,從而產生更易維護和理解的程式碼庫。
  7. 六邊形架構:此模式以一個核心為中心來構建應用程式,透過埠和適配器來實現核心與外部系統之間的通訊。
  8. CQRS(命令查詢責任分離):此模式將應用程式的讀取與寫入模型分離,以實現更高效的查詢和更好的可擴展性。
  9. 反應式架構:此模式是一組設計原則,旨在建立具備韌性、可擴展性和響應性的系統,能夠對環境變化做出回應。
  10. 乾淨架構:此模式強調應用程式不同層之間的關注點分離,目標是產生易於閱讀、測試和維護的程式碼。

總結

架構模式是企業架構中一種重要的設計技術,為架構師提供了一種設計有效解決方案來應對常見問題的方法。透過提供過去已被證明有效的解決方案藍圖,架構模式可幫助架構師節省時間和資源,同時提升解決方案的整體品質。在本文中,我們提供了一個在業務應用開發情境下架構模式的範例,特別是在單一登入(SSO)的背景下。透過使用單一登入模式,組織可以提供無縫的使用者體驗,減少管理使用者帳戶的行政負擔,同時提升使用者滿意度並降低支援服務中心的支援成本。

發佈留言