什麼是三位一體架構Trinity Architecture？ – Oregor

banq發表於2019-05-03
架構Go

這裡提出的Trinity Architecture是後端企業應用程式的架構模式。它源於採用依賴性倒置原理（DIP）的典型4層架構。它非常適合（但不限於）領域驅動設計（DDD）應用程式。
三位一體的三大支柱是：
  • 所述領域模型（DOMAIN）
  • 公共應用程式程式設計介面（API）
  • 輔助服務（AUX）

Trinity強調平衡不受控制的靈活性和一致性。它提供了八個頂級模組的具體實施指南。

什麼是三位一體架構Trinity Architecture？ – Oregor

依賴規則是：
圓圈內的圓圈：外圈取決於內圈。
圓圈外的圓圈：外圓使用（客戶端）或實現（細節）內部圓。

Github提供支援工具和庫。

流行架構模式的簡要概述
一開始，當電腦科學出現在50年代/ 60年代時，就沒有我們今天所知的架構。開發人員透過最佳化演算法和資料結構來解決問題。
軟體架構一詞在20世紀90年代初才開始流行。原因是客戶端 - 伺服器系統的興起。使用客戶端 - 伺服器系統，出現了多層體系結構的模式。
後來，在同一個十年中，出現了分層架構。分層的系統將系統分解為邏輯層而不是物理層。
在2000年代，基於依賴性倒置原則出現了新的架構模式。他們的主要目標是解決分層架構的緊耦合問題。

1. 多層架構
有史以來最流行的架構是多層架構。該模式不指定層數，而是一個簡單的規則：一層可以與其下面的任何層耦合，但從不與高於它的層耦合。
許多團隊可能會爭論分層架構中合適的層數。
Martin Fowler（2002）建議三層。（1）表現，（2）領域，和（3）資料來源。
Eric Evans（2003）建議四層。（1）使用者介面，（2）應用，（3）領域，以及（4）基礎設施。
分層架構的好處

  • 簡單
  • 一致性
  • 關注點分離

分層架構的缺點
  • 缺乏內建的可擴充套件性
  • 隱藏的用例
  • 業務邏輯可能從UI擴充套件到資料庫
  • 交換框架和技術很麻煩，如果不是禁止的話
  • 複雜的測試過程
  • 存在太多，不必要的層次的風險

2. 依賴倒置原則
Robert C. Martin 於1996年制定了依賴性倒置原則（DIP）。它代表“ SOLID ”原則中的字母“ D ” 。今天，它是物件導向程式設計中最著名的原則之一。

DIP的正式定義是：
A.高階模組不應該依賴於低階模組。兩者都應該依賴於抽象（介面）。
B.抽象不應該依賴於細節。細節（類）應該取決於抽象。

Vaughn Vernon（2013）演示瞭如何在典型的4層架構中應用DIP：

什麼是三位一體架構Trinity Architecture？ – Oregor
透過這種簡單的反轉，領域層是所有其他層依賴的域層。這種方法消除了與基礎設施層的直接耦合。

3基於DIP的架構
在2000年代中期之後，應用程式架構出現了一系列想法。

  • 埠和介面卡（六角形），Alistair Cockburn，2005年
  • 洋蔥傑弗裡巴勒莫，2008年
  • 羅伯特C.馬丁的清潔建築，2012/2017年

雖然它們的細節各不相同，但它們的目標是相同的。它們都旨在透過DIP 更好地分離關注點。我們可以稱這個系列的架構模式同心Concentric。
根據Robert C. Martin的說法，他們背後的依賴規則是：
原始碼依賴項必須指向內部，指向更高階別的策略。

基於DIP的架構的好處
  • 獨立於UI
  • 獨立於資料庫和其他外部系統
  • 獨立於技術特定的庫和框架
  • 可互換的基礎設施模組
  • 任意數量和型別的客戶端
  • 可測試

基於DIP的架構的缺點
  • 複雜
  • 缺少模板（洋蔥除外）
  • 前幾十年的模糊術語
  • 易受錯誤依賴和模組結構的影響（如果做得不對）
  • 如何選擇模式？


三位一體的形成
Trinity的目標是解決基於DIP的架構的缺點。在本節中，將形成它的形式。所需的步驟是：

  • 從典型的4層開始，定義通用與特定層
  • 定義嚴格和輕鬆的依賴關係
  • 應用DIP
  • 包括應用程式模組並構成Trinity體系結構

1.定義通用和特定層
Trinity的起點是典型的4層，正如埃文斯在2003年所提出的那樣。當時，諸如REST之類的技術對IT社群來說是未知的。我們現在將術語調整為最新標準：
  1. 客戶端、
  2. API、
  3. 領域層
  4. 輔助層


看看上面Vaughn Vernon（2013）轉換到這四個層的對映過程：
  • 使用者介面層 - >客戶端：今天應用程式不僅限於單個使用者介面客戶端。相反，可以有許多客戶端。它們可以存在很多形式（即REST客戶端，Web MVC客戶端等）
  • 應用層 - >（公共）API：應用層本身不區分公共和內部服務。在這裡，我們將它強制為一個特定的層，透過將其重新命名為（Public）API來表示其目的。
  • 領域層 - >領域層：領域層是應用程式的核心，已經是一個非常特殊的層，它仍然保持原樣。
  • 基礎設施層 - >輔助：基礎設施可能令人困惑，特別是對於初級開發人員。人們可能只考慮物理伺服器，例如資料庫或訊息伺服器。但這不是唯一的例子。例如，基礎設施也是實現複雜加密演算法的服務。因此，我們用術語輔助替換術語基礎設施。輔助程式更好地描述了有助於應用程式目的的任何內容。


2. 定義嚴格和寬鬆的依賴關係
在分層體系結構中，層之間有兩種型別的耦合：
  • 嚴格：只允許耦合到它下面的一層。
  • 相關：任何更高階別的層都可以耦合到它下面的任何層。


應用DIP

在下一步中，我們將DIP應用於除了第一個以外下面的所有層，即API客戶端。這是最關鍵的一步。

什麼是三位一體架構Trinity Architecture？ – Oregor

  • API只定義了DTO的和抽象。
  • Domain領域層定義的模型，它需要所有的抽象。因此，我們刪除了與AUX層的耦合。
  • AUX層定義了應用程式所需的DTO和抽象。
  • API細節： 實現的API抽象使用的領域和AUX抽象。
  • DOMAIN詳細： 實施的DOMAIN抽象
  • AUX細節： 落實的AUX抽象
  • API客戶端使用的API抽象，不是API詳細資訊。

由於前三個模組僅定義抽象，因此它們與框架無關。

包括應用程式（APP）模組的實戰圖
接下來，我們包括應用程式模組，它是引導應用程式所必需的。它還負責配置APP，橫切關注點等。
透過旋轉和重新組織塊，我們現在可以形成三位一體架構。

什麼是三位一體架構Trinity Architecture？ – Oregor
最下面一行是Trinity Core，它們與框架/技術無關。上排是三位一體組合。它提供實現和使用Trinity Core。

另一種觀點是圓形的，在文章的頂部描繪。

三位一體架構
1. 核心
三位一體建築的三大支柱是：

  • 域：域模型
  • API：公共應用程式程式設計介面
  • AUX：輔助服務

這些模組中的每一個都不依賴於其餘任何一個。他們的作用是僅定義DTO，模型和抽象。他們也應該不會有任何關於框架相關的庫的依賴關係。唯一可接受的例外是如果需要，使用框架特定註釋。

2 API詳細資訊
該API詳細是連線三個獨立的元件的API，AUX和DOMAIN的。
它的作用是透過使用Domain和Auxiliary模型以及抽象來實現API。除了特定於框架的註釋之外，API Detail仍然是框架不可知的。

3 API客戶端
該體系結構支援新增任意數量的API客戶端。該API客戶端只依賴於抽象API和不域模型或輔助服務。透過這種方式，我們確保每個用例始終都有一個應用程式入口點。

4 AUX詳細資訊
該AUX細節提供應用程式所需的實現。您應該根據角色將細節分成不同的模組。例如：
  • 文件儲存
  • 簡訊服務
  • SMTP服務
  • 等等

5 域詳細資訊
該層詳細提供了應用程式所需的實現。您應該根據角色將細節分成不同的模組。例如：
  • 持久儲存資料庫
  • 領域服務
  • 支付閘道器
  • 模板引擎
  • 等等

6 APP
Bootstraps並配置應用程式。

相關工具和工作
一個三位一體的架構的演示 for Java是可在Github上。
模組的名稱與Trinity Architecture圖中使用的模組名稱相比為1：1。

Java的Trinity Scaffolder
使用Trinity Scaffolder可以用Java生成自己的專案。

trinity4J

trinity4J是一組面向Java應用程式的域驅動設計庫。它非常適合Trinity Architecture。

PolyGenesis
Trinity Architecture是一個名為PolyGenesis的更大專案的一部分。

PolyGenesis是跨語言自動程式碼生成的開源平臺。它側重於 DDD和 UI。


結論
​​​​​​​Trinity Architecture的特點是：

  • 清晰的術語和明確定義的模組結構
  • 框架獨立核心（API，AUX，DOMAIN）
  • 任意數量的API客戶端，域詳細資訊和輔助詳細資訊
  • 可互換的技術和框架
  • 可測試
  • 更好地分配團隊成員
  • 學習曲線低
  • 支援工具和庫

相關文章