View a markdown version of this page

マイクロフロントエンド境界の特定 - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

マイクロフロントエンド境界の特定

チームの自律性を向上させるために、アプリケーションが提供するビジネス機能は、相互に最小限の依存関係で複数のマイクロフロントエンドに分解できます。

前述の DDD 方法論に従って、チームはアプリケーションドメインをビジネスサブドメインと境界コンテキストに分割できます。その後、自律チームは境界コンテキストの機能を所有し、それらのコンテキストをマイクロフロントエンドとして配信できます。

明確に定義された境界コンテキストは、機能的な重複とコンテキスト間のランタイム通信の必要性を最小限に抑える必要があります。必要な通信は、イベント駆動型メソッドで実装できます。これは、マイクロサービス開発のイベント駆動型アーキテクチャとは異なります。

適切に設計されたアプリケーションは、新しいチームによる将来の拡張機能の提供もサポートし、お客様に一貫したエクスペリエンスを提供する必要があります。

モノリシックアプリケーションをマイクロフロントエンドにスライスする方法

概要セクションには、ウェブページで独立した機能コンテキストを識別する例が含まれています。ユーザーインターフェイスの機能を分割するためのいくつかのパターンが表示されます。

たとえば、ビジネスドメインがユーザージャーニーのステージを形成する場合、フロントエンドの垂直分割を適用できます。この場合、ユーザージャーニーのビューのコレクションはマイクロフロントエンドとして配信されます。次の図は、カタログ、チェックアウト、請求書の各ステップが別々のマイクロフロントエンドとして別々のチームによって配信される垂直分割を示しています。

各マイクロフロントエンドには、ヘッダー、カタログ、サブスクリプションの詳細、フッターがあります。

一部のアプリケーションでは、垂直分割だけでは十分ではない場合があります。たとえば、一部の機能を多くのビューで提供する必要がある場合があります。これらのアプリケーションでは、混合分割を適用できます。次の図は、ステーションファインダーとルートエクスプローラーのマイクロフロントエンドの両方がマップビュー機能を使用する混合分割ソリューションを示しています。

ステーションファインダーの Team Discover と Route Explorer の Team Route はどちらも、チームマップが所有するマップビューを使用します。

ポータルタイプまたはダッシュボードタイプのアプリケーションでは、通常、フロントエンド機能が 1 つのビューにまとめられます。これらのタイプのアプリケーションでは、各ウィジェットをマイクロフロントエンドとして配信でき、ホスティングアプリケーションはマイクロフロントエンドが実装する必要がある制約とインターフェイスを定義します。

このアプローチは、ビューポートのサイズ設定、認証プロバイダー、構成設定、メタデータなどの懸念をマイクロフロントエンドが処理するメカニズムを提供します。これらのタイプのアプリケーションは、拡張性のために最適化されます。新機能は、ダッシュボード機能をスケールするために新しいチームによって開発できます。

次の図は、チームダッシュボードの一部である 3 つのチームによって開発されたダッシュボードアプリケーションを示しています。

現在のマルチチームダッシュボードアプリケーション。将来のチームによる新機能の可能性。

この図では、将来のビューは、チームダッシュボードとダッシュボード機能をスケールするために新しいチームが開発した新機能を表しています。

ポータルアプリケーションとダッシュボードアプリケーションは通常、UI で混合分割を使用して機能を構成します。マイクロフロントエンドは、位置やサイズの制約など、明確に定義された設定で設定できます。