マイクロフロントエンド境界の識別

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

前述の DDD 方法論に従って、チームはアプリケーションドメインをビジネスサブドメインと境界コンテキストに分割できます。その後、自律チームは境界コンテキストの機能を所有し、それらのコンテキストをマイクロフロントエンドとして配信できます。懸念事項の分離の詳細については、「サーバーレスランド図」を参照してください。

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

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

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

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

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

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

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

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

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

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

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