識別微前端邊界 - AWS 方案指引

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

識別微前端邊界

為了提高團隊自主性,應用程序提供的業務能力可以分解為幾個微前端,而彼此之間的依賴性最小。

遵循先前討論的 DDD 方法,專案團隊可以將應用程式網域劃分為企業子網域和有界的前後關聯。然後,自治團隊可以擁有其邊界上下文的功能,並以微觀前端的形式提供這些情境。如需關注點分離的詳細資訊,請參閱無伺服器土地圖表

定義良好的有界上下文應該最大限度地減少功能重疊和跨上下文運行時通信的需求。所需的通信可以使用事件驅動的方法來實現。這與微服務開發的事件驅動架構沒有什麼不同。

架構良好的應用程式也應該支援新團隊提供 future 的擴充功能,以便為客戶提供一致的體驗。

如何將整體應用程式切割成微前端

概觀」一節包含識別網頁上獨立功能前後關聯的範例。出現幾種在用戶界面上拆分功能的模式。

例如,當業務網域形成使用者旅程的階段時,可以在前端套用垂直分割,其中使用者旅程中的檢視集合會以微前端形式提供。下圖顯示垂直分割,其中「目錄」、「結帳」和「發票」步驟是由不同團隊作為單獨的微型前端進行交付。

每個微前端具有頭,目錄,訂閱詳細信息和頁腳。

對於某些應用程序,單獨垂直拆分可能是不夠的。例如,某些功能可能需要在許多視圖中提供。對於這些應用程式,您可以套用混合分割。下圖顯示混合分割解決方案,其中 Station 搜尋器和 Route 總管的微型前端都使用地圖檢視功能。

車站查找器的團隊發現和路線瀏覽器的團隊路線都使用團隊地圖擁有的地圖視圖。

入口類型或儀表板類型的應用程序通常將前端功能集成在一個單一視圖中。在這些類型的應用程式中,每個 Widget 都可以作為微型前端交付,而託管應用程式則定義微前端應實作的限制和介面。

此方法為微前端提供了一種機制,以處理諸如視埠大小調整、驗證提供者、組態設定和中繼資料等問題。這些類型的應用程式最佳化可擴充性。新團隊可以開發新功能以擴展儀表板功能。

下圖顯示由屬於「小組控制面板」一部分的三個個別團隊開發的儀表板應用程式。

當前的多團隊儀表板應用程序,future 團隊可以使用新功能。

在圖中,future 的檢視表示新團隊為擴展「團隊控制面板」和儀表板功能而開發的新功能。

入口網站和儀表板應用程式通常會在 UI 中使用混合分割來構成功能。微型前端可透過明確定義的設定進行配置,包括位置和大小限制。