本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 概觀
## 網域驅動設計 (DDD)
在[網域驅動設計 (DDD)](https://www.oreilly.com/library/view/implementing-domain-driven-design/9780133039900/) 中，網域是軟體系統的核心。網域模型會在您開發任何其他模組之前先定義，而且不依賴其他低階模組。相反地，資料庫、簡報層和外部 APIs等模組都取決於網域。
在 DDD 中，架構師會使用商業邏輯型分解而非技術分解，將解決方案分解為受限內容。此方法的優點會在 [目標業務成果](#business-outcomes)章節中討論。
當團隊使用六邊形架構時，DDD 更容易實作。在六邊形架構中，應用程式核心是應用程式的中心。它會透過連接埠和轉接器從其他模組解耦，並且沒有其他模組的相依性。這與 DDD 完美一致，其中網域是解決業務問題的應用程式核心。本指南提議一種方法，其中您將六邊形架構的核心建模為邊界內容的網域模型。下一節會更詳細地說明六邊形架構。
本指南未涵蓋 DDD 的所有層面，這是一個非常廣泛的主題。若要進一步了解，您可以檢閱[域語言](https://www.domainlanguage.com/ddd/)網站上列出的 DDD 資源。
## 六角形架構
六角型架構也稱為*連接埠和轉接器*或*小齒輪架構*，是管理軟體專案中相依性反轉的原則。六角架構在開發軟體時提升了對核心網域商業邏輯的高度關注，並將外部整合點視為次要。六角型架構可協助軟體工程師採用測試驅動開發 (TDD) 等良好實務，進而促進[架構演進](https://dzone.com/articles/pattern-of-the-month-red-green-refactor)，並協助您長期管理複雜的網域。
讓我們比較六邊形架構與傳統分層架構，這是建立結構化軟體專案模型時最熱門的選擇。這兩種方法之間存在細微但強大的差異。
在分層架構中，軟體專案以層結構，代表廣泛的問題，例如商業邏輯或簡報邏輯。此架構使用相依性階層，其中最上層對它們下方的層具有相依性，但不是反之亦然。在下圖中，簡報層負責使用者互動，因此包含使用者介面、APIs、命令列介面和類似的元件。呈現層與實作網域邏輯的業務層有相依性。商業層又對資料存取層和多個外部服務具有相依性。
此組態的主要缺點是相依性結構。例如，如果在資料庫中存放資料的模型變更，這會影響資料存取界面。資料模型的任何變更也會影響業務層，而業務層依賴於資料存取界面。因此，軟體工程師無法在不影響網域邏輯的情況下進行任何基礎設施變更。這反過來會增加迴歸錯誤的可能性。
六角形架構以不同的方式定義相依性關係，如下圖所示。它會集中在定義所有界面的網域商業邏輯上進行決策。外部元件會透過稱為*連接埠*的界面與商業邏輯互動。連接埠是定義網域與外部世界互動的抽象。每個基礎設施元件都必須實作這些連接埠，因此這些元件的變更不會再影響核心網域邏輯。
周圍的元件稱為*轉接器*。轉接器是外部世界與內部世界之間的代理，並實作網域中定義的連接埠。轉接器可以分為兩個群組：主要和次要。主要轉接器是軟體元件的進入點。它們允許外部演員、使用者和服務與核心邏輯互動。 AWS Lambda 是主要轉接器的良好範例。它與可叫用 Lambda 函數做為進入點的多個 AWS 服務整合。次要轉接器是外部服務程式庫包裝函式，可處理與外部世界的通訊。次要轉接器的良好範例是用於資料存取的 Amazon DynamoDB 用戶端。
## 目標業務成果
本指南中討論的六邊形架構可協助您達成下列目標：
+ [透過改善開發週期來縮短上市時間](improve-dev-cycle.md)
+ [改善軟體品質](improve-software-quality.md)
+ [更輕鬆地適應變更](adapt-to-change.md)
以下各節會詳細討論這些程序。