六邊形架構教程：構建可維護的Web應用程式 - DEV

應用層表示為六邊形。在六邊形中，我們有我們的領域實體和使用它們的用例。如我們所見，沒有傳出依賴項。我們所有的依賴都指向中心。六邊形的內部，或域，只取決於它自己。這確保了業務邏輯與技術層分離。它還確保我們可以重用域邏輯。如果我們改變我們的堆疊，它不會對域程式碼產生影響。核心擁有主要的業務邏輯和業務規則。
在六邊形之外，我們看到與我們的應用程式互動的不同介面卡。不同的介面卡將與應用程式的不同方面進行互動。例如，我們可以有一個與 Web 瀏覽器互動的網路介面卡，一些與外部系統互動的介面卡，以及一個與資料庫互動的介面卡。左側的介面卡驅動我們的應用程式，因為它們呼叫我們的應用程式核心。右側的介面卡由我們的應用程式驅動，因為它們由我們的應用程式核心呼叫。
介面卡可以是應用程式的外部 API，也可以是其他系統的客戶端。介面卡使用埠來啟動與應用程式的互動。REST 控制器將是介面卡的一個示例。應用程式核心提供埠，以便它可以與介面卡進行通訊。埠允許我們將介面卡插入核心域。我們可以將埠視為不可知的入口點。
六邊形架構不應該依賴於任何技術框架。這包括外部註釋，例如 Java Persistence API (JPA) 和 Jackson。
 

優於傳統分層架構
六邊形架構與傳統的分層架構背道而馳。六邊形架構的主要區別之一是使用者介面可以換出。使用六邊形架構而不是分層架構有很多好處。讓我們看看一些優點、缺點和用例：
優點

• 可維護性：我們的應用程式具有很高的可維護性，因為我們應用程式的一個領域的變化不會影響其他領域。
• 靈活性：我們可以輕鬆地在不同的應用程式之間切換，並且可以在不更改原始碼的情況下新增新的介面卡。
• 簡單測試：由於我們的程式碼與外界的實現細節是分離的，所以我們可以單獨測試。
• 不可知：由於應用程式獨立於外部服務，我們可以在構建外部服務之前開發核心。

• 解耦：由於中間類，我們的應用程式的效能可能會受到影響。
• 除錯：有時很難理解和除錯介面卡。
• 複雜：六邊形架構有時會令人困惑，因為我們應該考慮的外部結構並不總是很明顯。

• 一種銀行應用程式，允許我們從一個帳戶向另一個帳戶匯款
• 一個允許我們申請貸款、透過驗證並在我們的應用程式更新時接收更新的系統
• 一個忠誠度應用程式，允許我們註冊客戶並升級或降級他們的會員資格

六邊形架構原理 
現在，讓我們來看看六邊形架構背後的一些基本原則。

• 單一職責原則

• 依賴倒置

在上面的結構中，我們在域層有一個服務，它與儲存庫和持久層中的實體一起工作。我們可以為域層的倉庫建立一個介面，讓持久層的倉庫實現它。這允許我們將域邏輯從其對永續性程式碼的依賴中解放出來。這是它的樣子：

使用埠和介面卡隔離邊界
埠和介面卡允許我們以完全隔離的模式執行我們的應用程式。六邊形架構使用埠和介面卡來說明內部和外部之間的通訊。埠是我們應用程式的邊界。有兩種埠：主埠和輔助埠。
主埠或入站埠是外部世界與應用程式核心之間的初始通訊點。主埠是請求到達應用程式的地方。應用程式核心使用輔助埠或出站埠將資料上游到外部服務。
介面卡作為我們埠的實現。有兩種介面卡：主要和次要。主要介面卡是主要埠的實現。它們獨立於應用程式的核心。輔助介面卡是輔助埠的實現。它們也獨立於應用程式核心。
 

六邊形架構示例
在文章的前面，我們列出了一些六邊形架構用例。現在，我們將在一個簡短的教程中開始使用其中一個用例。我們將遵循允許我們從一個帳戶向另一個帳戶匯款的應用程式的用例。讓我們看一下我們將編寫的用於建立SendMoneyService類的程式碼：

package buckpal.account.application.service;

@RequiredArgsConstructor
@Transactional
public class SendMoneyService implements SendMoneyUseCase {

 private final LoadAccountPort loadAccountPort;
 private final AccountLock accountLock;
 private final UpdateAccountStatePort updateAccountStatePort;

 @Override
 public boolean sendMoney(SendMoneyCommand command) {
   // TODO: validate business rules
   // TODO: manipulate model state
   // TODO: return output
 }
}