本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
適應變更
軟體系統往往會變得複雜。其中一個原因可能是經常變更業務需求，而且很少時間相應地調整軟體架構。另一個原因是，在專案開始時設定軟體架構以適應頻繁變更的投資不足。無論原因為何，軟體系統都可能變得複雜，幾乎無法進行變更。因此，從專案開始時建置可維護的軟體架構非常重要。良好的軟體架構可以輕鬆適應變更。
本節說明如何使用易於適應非功能或業務需求的六邊形架構來設計可維護的應用程式。
使用連接埠和轉接器來適應新的非功能需求
做為應用程式的核心，網域模型會定義外部世界滿足業務需求所需的動作。這些動作是透過抽象定義，稱為連接埠。這些連接埠由不同的轉接器實作。每個轉接器都負責與另一個系統的互動。例如，您可能有一個用於資料庫儲存庫的轉接器，以及另一個用於與第三方 API 互動的轉接器。網域不知道轉接器實作，因此很容易將一個轉接器取代為另一個轉接器。例如，應用程式可能會從 SQL 資料庫切換到 NoSQL 資料庫。在此情況下，必須開發新的轉接器，以實作網域模型定義的連接埠。網域對資料庫儲存庫沒有相依性，並使用抽象進行互動，因此不需要變更網域模型中的任何內容。因此，六邊形架構可輕鬆適應非功能需求。
使用命令和命令處理常式來適應新的業務需求
在傳統分層架構中，網域取決於持久性層。如果您想要變更網域，您也必須變更持久性層。相比之下，在六邊形架構中，網域不依賴軟體中的其他模組。網域是應用程式的核心，所有其他模組 （連接埠和轉接器） 都取決於網域模型。網域使用相依性反轉原則，透過連接埠與外部世界通訊。相依性反轉的好處是您可以自由變更網域模型，而不會害怕破壞程式碼的其他部分。由於網域模型會反映您嘗試解決的業務問題，因此更新網域模型以適應不斷變化的業務需求並非問題。
當您開發軟體時，問題分離是必須遵循的重要原則。若要達成此區隔，您可以使用稍微修改的命令模式。這是一種行為設計模式，其中所有完成操作的必要資訊都會封裝在命令物件中。然後，命令處理常式會處理這些操作。命令處理常式是接收命令、變更網域狀態，然後將回應傳回給發起人的方法。您可以使用同步 APIs 或非同步佇列等不同的用戶端來執行命令。建議您針對網域上的每個操作使用命令和命令處理常式。透過遵循此方法，您可以引進新的命令和命令處理常式來新增功能，而無需變更現有的商業邏輯。因此，使用命令模式可讓您更輕鬆地適應新的業務需求。
使用服務外牆或 CQRS 模式來解耦元件
在六邊形架構中，主要轉接器負責將來自用戶端的傳入讀取和寫入請求鬆散地耦合到網域。有兩種方式可以實現這種鬆散耦合：使用服務外牆模式或使用命令查詢責任隔離 (CQRS) 模式。
服務外牆模式提供面向前方的界面，為呈現層或微服務等用戶端提供服務。服務外牆為用戶端提供數個讀取和寫入操作。它負責將傳入請求轉移到網域，並將從網域接收的回應映射到用戶端。對於具有多項操作的單一責任的微服務，使用服務外牆很容易。不過，使用服務外牆時，很難遵循單一責任和開放式原則。單一責任原則指出每個模組應僅負責軟體的單一功能。開放關閉原則指出程式碼應開放延伸，並關閉以進行修改。隨著服務外觀的擴展，所有操作都收集在一個界面中，將更多的相依性封裝在其中，並且更多開發人員開始修改相同的外觀。因此，我們建議只在明確表示服務在開發期間不會大幅擴展時，才使用服務外牆。
在六邊形架構中實作主要轉接器的另一種方法是使用 CQRS 模式，這會使用查詢和命令來區隔讀取和寫入操作。如前所述，命令是包含變更網域狀態所需的所有資訊的物件。命令是由命令處理常式方法執行。另一方面，查詢不會改變系統的狀態。其唯一目的是將資料傳回給用戶端。在 CQRS 模式中，命令和查詢會在不同的模組中實作。這對於遵循事件驅動架構的專案特別有利，因為命令可以實作為非同步處理的事件，而查詢可以使用 API 同步執行。查詢也可以使用針對它最佳化的不同資料庫。CQRS 模式的缺點是實作需要比服務外牆更多的時間。對於您計劃長期擴展和維護的專案，我們建議您使用 CQRS 模式。命令和查詢提供有效的機制，用於套用單一責任原則和開發鬆耦合的軟體，尤其是在大規模專案中。
CQRS 的長期優勢很大，但需要初始投資。因此，我們建議您在決定使用 CQRS 模式之前仔細評估專案。不過，您可以從一開始就使用命令和命令處理常式來建構應用程式，而不需分開讀取/寫入操作。如果您決定稍後採用該方法，這將協助您輕鬆地重構 CQRS 的專案。
組織擴展
六邊形架構、網域驅動設計和 （選用） CQRS 的組合可讓您的組織快速擴展產品。根據 Conway 法律，軟體架構往往會演進以反映公司的通訊結構。此觀察歷史上具有負面含義，因為大型組織通常會根據資料庫、企業服務匯流排等技術專業知識來建構團隊。這種方法的問題在於，產品和功能開發一律涉及交叉考量，例如安全性和可擴展性，這需要團隊之間持續通訊。以技術功能為基礎的結構化團隊會在組織中產生不必要的孤立，這會導致溝通不佳、缺乏擁有權，以及對大局視而不見。最後，這些組織問題會反映在軟體架構中。
另一方面，Inverse Conway Maneuver 會根據提升軟體架構的網域來定義組織結構。例如，跨職能團隊必須負責一組特定的邊界內容，這些內容是透過使用 DDD 和事件風暴來識別。這些邊界內容可能會反映產品的非常特定功能。例如，帳戶團隊可能需要負責付款內容。每個新功能都會指派給具有高度凝聚性和鬆散耦合責任的新團隊，因此他們只能專注於該功能的交付，並減少上市時間。團隊可以根據功能的複雜性進行擴展，因此可以將複雜的功能指派給更多工程師。
