準則: 分層
這個準則簡介系統的分層策略。
關係
相關元素
主要說明

分層準則

分層提供一種利用如何在各層次之間形成關係的特定規則來將子系統分成幾個組的邏輯分割。 分層可用來限制跨子系統的相依性,結果系統的耦合性會更寬鬆,因而也更容易維護。

以下是一些子系統分組準則所遵循的型樣:

  • 可見度。子系統只能相依於同層及下一層子系統。
  • 變化性
    • 在最高的層次中,放置會隨著使用者需求的變更而改變的元素。
    • 在最低的層次中,放置會隨著實作平台(硬體、語言、作業系統、資料庫等)的變更而改變的元素。
    • 在中間,放置一般而言適用於大範圍系統和實作環境的元素。
    • 當這些廣泛種類內的其他分割有助於組織模型時,加入新的層次。
  • 一般化。抽象模型元素通常放在模型中較低的位置。如果不是隨著實作而不同,它們傾向於會往中間層移動。
  • 層次數目。如果是小型系統,三個層次便已足夠。如果是複雜系統,5-7 個層次通常便已足夠。不論任何複雜程度,當超出 10 層時,層次數目越多,越應該加以懷疑。以下是一些基本原則:

# 類別

# 層次

0 - 10

不需要分層

10 - 50

2 層

25 - 150

3 層

100 - 1000

4 層

特定層次內的子系統和套件只應該相依於相同層次及下一較低層次內的子系統。當無法依照這個方式來限制相依性時,架構會退化,系統會變成容易損壞且難以維護。

異常狀況包括子系統需要直接存取較低層服務的案例:這時需要明智的決策,決定如何處理整個系統所需要的主要服務,如列印、傳送訊息等。如果解決方案是在中間層有效實作呼叫轉遞,將訊息限制於較低層次便沒什麼價值。

分割型樣

在系統最上面的各層次內,進一步分割可能有助於組織模型。下列分割準則提供不同的問題,供您考量:

  • 使用者組織。子系統可以依照反映商業組織功能的組織方式來組織(例如,依部門來分割)。這項分割通常發生在設計的早期,因為現有的企業模型有很強的組織分割結構。這個組織型樣通常只會影響特定應用程式專用服務的最上面幾個層次,且通常會隨著設計的進展而消失。
    • 依使用者組織來進行分割可能是好的模型起點。
    • 使用者組織的結構並不具備長期穩定性(因為可能進行企業重組),它並不是好的長期系統分割基礎。系統的內部組織應該使系統的發展和維護工作與它支援的商業組織無關。
  • 能力和/或技術區域。子系統的組織可以在開發組織內的不同小組之間,分割模型組件的責任。這通常是發生在系統的中間或較低層,且會反映複雜基礎架構技術之開發和支援期間的技術特殊化需求。這類技術的範例包括網路和分散管理、資料庫管理、通訊管理及流程控制,以及其他。沿著能力線來分割也可以出現在較上面的層次中,這時需要問題領域中的特殊能力來瞭解和支援關鍵商業功能;例如,電信呼叫管理、安全交易、保險索賠處理,以及空中交通管制等。
  • 系統分佈。在系統的任何層次內,各層次都可以進一步「水平」分割來反映實際的功能分佈。
    • 進行分割以反映分佈,有助於將系統執行時所進行的網路通訊視覺化。
    • 不過,如果部署模型大幅改變,進行分割以反映分佈有可能使系統更不容易變動。
  • 秘密區域。部分應用程式,尤其是需要開發和/或支援特殊安全檢查的應用程式,必須沿著安全存取專用權的線來進行額外的分割。秘密區域的存取控制軟體必須由通過適當安全檢查的人員來開發和維護。如果有這個背景的專案人數有限,便必須將需要特殊安全檢查的功能,分割到在其他子系統之外獨立開發的子系統中,使秘密區域的介面成為這些子系統唯一可見的部分。
  • 變化區域。可能是選用的,因而只在系統某些變式中開發的功能,應該組織到獨立的子系統中,在系統強制性的功能之外獨立開發和交付。