這裡提出的Trinity Architecture是後端企業應用程式的架構模式。它源於採用依賴性倒置原理（DIP）的典型4層架構。它非常適合（但不限於）領域驅動設計（DDD）應用程式。

三位一體的三大支柱是：

• 所述領域模型（DOMAIN）
• 公共應用程式程式設計介面（API）
• 輔助服務（AUX）

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

依賴規則是：

圓圈內的圓圈：外圈取決於內圈。

圓圈外的圓圈：外圓使用（客戶端）或實現（細節）內部圓。

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：

通過這種簡單的反轉，領域層是所有其他層依賴的域層。這種方法消除了與基礎設施層的直接耦合。

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客戶端。這是最關鍵的一步。

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

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

包括應用程式（APP）模組的實戰圖

接下來，我們包括應用程式模組，它是引導應用程式所必需的。它還負責配置APP，橫切關注點等。

通過旋轉和重新組織塊，我們現在可以形成三位一體架構。

最下面一行是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客戶端，域詳細資訊和輔助詳細資訊
• 可互換的技術和框架
• 可測試
• 更好地分配團隊成員
• 學習曲線低
• 支援工具和庫