本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 基礎概念
微型前端架構深受三個先前建築概念的啟發：
+ *領域驅動設計*是將複雜應用程序構建為一致領域的心理模型。
+ *分散式系統*是將應用程式建置為鬆散耦合子系統的一種方法，這些子系統是獨立開發並在自己的專用基礎架構上執行的。
+ *雲端運算*是以模型執行 IT 基礎架構即服務的一 pay-as-you-go 種方法。
## 領域驅動設計
領域驅動設計（DDD）是埃里克·埃文斯開發的範例。Evans 在 2003 年著作《[領域驅動設計：解決軟體核心的複雜性》中，假設軟體](https://www.amazon.com/gp/product/0321125215/)開發應該是由業務問題而不是技術問題所驅動。Evans 建議 IT 專案首先開發一種*無處不在的語言*，以幫助技術和領域專家找到共同的理解。基於這種語言，他們可以制定一個相互理解的商業現實模型。
很明顯，因為這種方法可能是，許多軟件項目遭受業務和 IT 之間的斷開。這些斷線通常會造成重大誤解，導致預算超支、品質下降或專案失敗。
Evans 引入了多個其他重要術語，其中一個是*有界的上下文*。有界的上下文是大型 IT 應用程序的自包含部分，其中包含僅針對一個業務問題的解決方案或實現。一個大型的應用程序將由通過集成模式鬆散耦合的多個有界上下文組成。這些有界的上下文甚至可以有自己的無處不在的語言的方言。例如，應用程式付款內容中的*使用者*可能與傳送內容中的*使用者*有不同的層面，因為付款期間的託運概念無關緊要。
埃文斯沒有定義有界上下文應該有多小或大。大小由軟件項目確定，並且可能會隨著時間的推移而發展。上下文邊界的良好指標是實體（域對象）和業務邏輯之間的凝聚程度。
在微前端的背景下，領域驅動的設計可以通過複雜的網頁例如航班預訂頁面來說明。
在此頁面上，主要構建塊是搜索表單，過濾器面板和結果列表。若要識別邊界，您必須識別獨立的功能前後關聯。此外，請考慮非功能性方面，例如可重用性，性能和安全性。最重要的指標是「屬於在一起的東西」是他們的溝通模式。如果架構中的某些元素必須經常通信並交換複雜的信息，則它們可能共享相同的有界上下文。
單獨的 UI 元素，如按鈕不是有界的上下文，因為它們在功能上不是獨立的。此外，整個頁面不適合有界的前後關聯，因為它可以分解為較小的獨立前後關聯。合理的方法是將搜尋表單視為一個有界前後關聯，並將結果清單視為第二個有界前後關聯。這兩個有界的上下文中的每一個現在都可以實現為一個單獨的微前端。
## 分散式系統
為了簡化維護並支持發展能力，大多數不平凡的 IT 解決方案都是模塊化的。在這種情況下，模塊化意味著 IT 系統由可識別的構建模塊組成，這些構建模塊通過接口進行分離以實現關注點分離。
除了是模塊化的，分佈式系統應該是獨立的系統在他們自己的權利。在一個僅僅模塊化的系統中，每個模塊都被理想地封裝並通過接口公開其功能，但它不能獨立部署，甚至不能單獨部署，甚至可以單獨運行。此外，模塊通常遵循相同的生命週期作為同一系統的其他模塊的一部分。另一方面，分散式系統的建構區塊都有自己的生命週期。應用領域驅動的設計範例，每個構建塊可以處理一個業務領域或子域，並存在於其自己的界限環境中。
當分佈式系統在構建期間進行交互時，常見的方法是開發快速識別問題的機制。例如，您可能會採用類型語言並在單元測試上進行大量投資。多個團隊可以在模塊的開發和維護上進行協作，這些模塊通常作為庫分發，供系統使用 npm，Apache Maven 和 pip 等工具一起使用。 NuGet
在執行階段期間，互動的分散式系統通常由個別團隊擁有。消耗相依性會導致作業複雜性，因為錯誤處理、效能平衡和安全性。集成測試和可觀察性的投資是降低風險的基礎。
當今分佈式系統最常見的例子是微服務。在微服務架構中，後端服務是由領域驅動的（而不是由 UI 或身份驗證等技術問題驅動），並由自治團隊擁有。微型前端共用相同的原則，將解決方案範圍擴展到前端。
## 雲端運算
雲端運算是透過 pay-as-you-go 模型購買 IT 基礎架構即服務的一種方式，而不是建立自己的資料中心，並購買硬體以便在內部部署進行操作。雲計算提供了以下幾個優點：
+ 您的組織能夠嘗試新技術，而無需預先做出龐大的長期財務承諾，從而獲得顯著的業務敏捷性。
+ 透過使用雲端供應商 AWS，您的組織就可以存取廣泛的低維護和高度整合的服務產品組合 (例如 API 閘道、資料庫、容器協調和雲端功能)。使用這些服務可讓您的員工更加專注於使您的組織與競爭對手區分開來的工作。
+ 當您的組織準備好在全球推出解決方案時，您可以將解決方案部署到世界各地的雲端基礎架構。
雲端運算透過提供高度管理的基礎架構來支援微前端。這使得跨職能團隊的 end-to-end 擁有權變得更加容易。雖然團隊應該具備強大的營運知識，但是基礎結構佈建、作業系統更新和網路等手動工作會令人分心。
由於微前端生活在有界的環境中，所以團隊可以選擇最合適的服務來運行它們。例如，團隊可以在雲端函式和運算容器之間進行選擇，並且可以在不同風格的 SQL 和 NoSQL 資料庫或記憶體內快取之間進行選擇。團隊甚至可以在高度整合的工具組上建置他們的微前端 [AWS Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/welcome.html)，例如為無伺服器基礎架構提供預先設定的建置區塊。