本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

概觀

網域驅動型設計 (DDD)

在網域驅動型設計 (DDD) 中，網域是軟體系統的核心。網域模型會在您開發任何其他模組之前先定義，且不依賴其他低階模組。相反地，資料庫、簡報層和外部 APIs等模組都取決於網域。

在 DDD 中，架構師使用商業邏輯型分解而非技術分解，將解決方案分解為受限內容。目標業務成果 本節會討論此方法的優點。

當團隊使用六邊形架構時，DDD 更容易實作。在六邊形架構中，應用程式核心是應用程式的中心。它透過連接埠和轉接器從其他模組分離，並且沒有其他模組的相依性。這與 DDD 完美一致，其中網域是解決業務問題的應用程式核心。本指南提供一種方法，可讓您將六邊形架構的核心建模為邊界內容的網域模型。下一節會更詳細地說明六邊形架構。

本指南未涵蓋 DDD 的所有層面，這是一個非常廣泛的主題。若要進一步了解，您可以檢閱域語言網站上列出的 DDD 資源。

六角形架構

六角形架構也稱為連接埠和轉接器或Onion 架構，是管理軟體專案中相依性反轉的原則。六角形架構有助於在開發軟體時高度專注於核心網域商業邏輯，並將外部整合點視為次要。六角形架構可協助軟體工程師採用良好的實務，例如測試驅動的開發 (TDD)，進而促進架構發展，並協助您長期管理複雜的網域。

讓我們比較六邊形架構與傳統分層架構，這是建立結構化軟體專案模型時最熱門的選擇。這兩種方法之間存在細微但強大的差異。

在分層架構中，軟體專案以層結構，代表廣泛的考量，例如商業邏輯或簡報邏輯。此架構使用相依性階層，其中頂層對它們下方的圖層具有相依性，而不是反之亦然。在下圖中，簡報層負責使用者互動，因此包含使用者介面、APIs、命令列界面和類似的元件。呈現層與實作網域邏輯的業務層有相依性。而商業層則依賴於資料存取層和多個外部服務。

此組態的主要缺點是相依性結構。例如，如果在資料庫中存放資料的模型變更，這會影響資料存取界面。資料模型的任何變更也會影響業務層，這與資料存取界面有相依性。因此，軟體工程師無法在不影響網域邏輯的情況下進行任何基礎設施變更。這反過來會增加迴歸錯誤的可能性。

六角形架構以不同的方式定義相依性關係，如下圖所示。它專注於圍繞定義所有界面的網域業務邏輯做出決策。外部元件會透過稱為連接埠的界面與商業邏輯互動。連接埠是定義網域與外部世界互動的抽象概念。每個基礎設施元件都必須實作這些連接埠，因此這些元件的變更不會再影響核心網域邏輯。

周圍的元件稱為轉接器。轉接器是外部世界與內部世界之間的代理，並實作網域中定義的連接埠。轉接器可以分為兩個群組：主要和次要。主要轉接器是軟體元件的進入點。它們允許外部演員、使用者和服務與核心邏輯互動。 AWS Lambda 是主要轉接器的良好範例。它與多個 AWS 服務整合，可調用 Lambda 函數作為進入點。次要轉接器是外部服務程式庫包裝函式，可處理與外部世界的通訊。次要轉接器的良好範例是用於資料存取的 Amazon DynamoDB 用戶端。

目標業務成果

本指南討論的六邊形架構可協助您達成下列目標：

以下各節會詳細討論這些程序。