

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

# 識別微型前端界限
<a name="micro-frontend-boundaries"></a>

為了改善團隊自主權，應用程式提供的業務功能可以分解為數個微型前端，彼此的相依性最低。

遵循先前討論的 DDD 方法，團隊可以將應用程式網域分解為業務子網域和邊界內容。然後，自主團隊可以擁有其邊界內容的功能，並以微型前端的形式交付這些內容。

定義明確的邊界內容應該將功能重疊和跨內容執行時間通訊的需求降至最低。可以使用事件驅動方法實作所需的通訊。這與微服務開發的事件驅動架構並無不同。

架構良好的應用程式也應該支援新團隊未來延伸模組的交付，以為客戶提供一致的體驗。

## 如何將單體應用程式分割為微型前端
<a name="monolith-slicing"></a>

[概觀](introduction.md#overview)區段包含識別網頁上獨立功能內容的範例。使用者介面上分割功能的多種模式隨即出現。

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



![每個微型前端都有標頭、目錄、訂閱詳細資訊和頁尾。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-vertical-split.png)


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



![Station finder 的 Team Discover 和 Route Explorer 的 Team Route 都使用 Team Map 擁有的 Map 檢視。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-mixed-split.png)


入口網站類型或儀表板類型應用程式通常會在單一檢視中整合前端功能。在這些類型的應用程式中，每個小工具都可以作為微型前端交付，託管應用程式定義微型前端應實作的限制條件和界面。

此方法為微型前端提供了一種機制，可處理檢視區大小、身分驗證提供者、組態設定和中繼資料等問題。這些類型的應用程式會針對可擴展性進行最佳化。新團隊可以開發新功能，以擴展儀表板功能。

下圖顯示由三個屬於 Team Dashboard 的個別團隊所開發的儀表板應用程式。



![目前的多團隊儀表板應用程式，未來團隊可能會推出新功能。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-team-dashboard.png)


在圖表中，未來檢視代表新團隊開發的新功能，以擴展團隊儀表板和儀表板功能。

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