基本的な概念

マイクロフロントエンドアーキテクチャは、3 つの以前のアーキテクチャ概念から大きく影響を受けています。

• ドメイン駆動型設計は、複雑なアプリケーションを一貫したドメインに構造化するためのメンタルモデルです。

• 分散システムは、独自に開発され、独自の専用インフラストラクチャで実行される疎結合サブシステムとしてアプリケーションを構築するためのアプローチです。

• クラウドコンピューティングは、IT インフラストラクチャを pay-as-you-go モデルでサービスとして実行するためのアプローチです。

ドメイン駆動型設計

ドメイン駆動型設計 (DDD) は、Eric Evans によって開発されたパラダイムです。2003 年の本「Domain-Driven Design: Tackling Complexity in the Heart of Software」では、Evans はソフトウェア開発は技術的な問題ではなくビジネス上の懸念によって推進されるべきだと想定しています。Evans は、IT プロジェクトが最初に、技術専門家とドメイン専門家が共通の理解を見つけるのに役立つユビキタスな言語を開発することを提案します。その言語に基づいて、ビジネス上の現実について相互に理解されたモデルを策定できます。

そのアプローチは明らかですが、多くのソフトウェアプロジェクトはビジネスと IT の切断に悩まされています。これらの切断は、多くの場合、大きな誤解を引き起こし、予算の超過、品質の低下、またはプロジェクトの失敗につながります。

Evans では、他の複数の重要な用語が導入されています。そのうちの 1 つが境界コンテキスト です。境界付きコンテキストは、1 つのビジネス上の懸念に対するソリューションまたは実装を含む大規模な IT アプリケーションの自己完結型セグメントです。大規模なアプリケーションは、統合パターンを介して疎結合された複数の境界コンテキストで構成されます。これらの境界コンテキストは、ユビキタス言語の独自の方言を持つこともできます。例えば、アプリケーションの支払いコンテキストのユーザーは、配送の概念が支払い中に無関係になるため、配送コンテキストのユーザーとは異なる側面を持つ場合があります。

Evans は、境界コンテキストの規模を定義しません。サイズはソフトウェアプロジェクトによって決定され、時間の経過とともに進化する可能性があります。コンテキストの境界を示す優れた指標は、エンティティ (ドメインオブジェクト) とビジネスロジックの間の結合度です。

マイクロフロントエンドのコンテキストでは、フライト予約ページなどの複雑なウェブページの例でドメイン駆動型設計を説明できます。

このページでは、主な構成要素は検索フォーム、フィルターパネル、結果リストです。境界を特定するには、独立した機能コンテキストを特定する必要があります。さらに、再利用性、パフォーマンス、セキュリティなどの非機能的な側面も考慮してください。「一緒に属するモノ」という最も重要な指標は、コミュニケーションパターンです。アーキテクチャの一部の要素が頻繁に通信し、複雑な情報を交換する必要がある場合、同じ境界コンテキストを共有する可能性があります。

ボタンなどの個々の UI 要素は機能的に独立していないため、境界コンテキストにはなりません。また、ページ全体は、より小さな独立したコンテキストに分割できるため、境界コンテキストには適していません。妥当な方法は、検索フォームを 1 つの境界コンテキストとして扱い、結果リストを 2 番目の境界コンテキストとして扱うことです。これら 2 つの境界コンテキストをそれぞれ個別のマイクロフロントエンドとして実装できるようになりました。

分散システム

メンテナンスを容易にし、進化する機能をサポートするために、単純な IT ソリューションの大部分はモジュール式です。この場合、モジュール式とは、IT システムが識別可能な構成要素で構成され、インターフェイスを介して分離され、懸念を分離することを意味します。

分散システムは、モジュール型であることに加えて、独自の独立したシステムである必要があります。単にモジュラーシステムの場合、各モジュールは理想的にはカプセル化され、インターフェイスを介してその関数を公開しますが、個別にデプロイしたり、単独で機能させたりすることはできません。また、モジュールは通常、同じシステムの一部である他のモジュールと同じライフサイクルに従います。一方、分散システムの構成要素には、それぞれ独自のライフサイクルがあります。ドメイン駆動型設計パラダイムを適用すると、各構成要素は 1 つのビジネスドメインまたはサブドメインに対処し、独自の境界コンテキストに属します。

構築中に分散システムが相互作用する場合、一般的なアプローチは、問題をすばやく特定するためのメカニズムを開発することです。例えば、型付き言語を採用して、ユニットテストに多額の投資を行う場合があります。複数のチームがモジュールの開発とメンテナンスに共同作業できます。多くの場合、npm、Apache Maven、 NuGetpip などのツールでシステムを消費するためのライブラリとして配布されます。

実行時には、対話型の分散システムは通常、個々のチームによって所有されます。依存関係を消費すると、エラー処理、パフォーマンスバランシング、セキュリティのために運用が複雑になります。統合テストとオブザーバビリティの成果は、リスクを軽減するために不可欠です。

今日の分散システムの最も一般的な例はマイクロサービスです。マイクロサービスアーキテクチャでは、バックエンドサービスは (UI や認証などの技術的な懸念によって駆動されるのではなく) ドメイン駆動型であり、自律型チームによって所有されます。マイクロフロントエンドは同じ原則を共有し、ソリューションの範囲をフロントエンドに拡張します。

クラウドコンピューティング

クラウドコンピューティングは、独自のデータセンターを構築し、オンプレミスで運用するためのハードウェアを購入するのではなく、 pay-as-you-go モデルを使用して IT インフラストラクチャをサービスとして購入する方法です。クラウドコンピューティングにはいくつかの利点があります。

• 組織は、大規模で長期的な財務上のコミットメントを事前に行うことなく、新しいテクノロジーを試すことができるため、ビジネスの俊敏性が大幅に向上します。

• などのクラウドプロバイダーを使用することで AWS、組織はメンテナンスが少なく、高度に統合されたサービス (API ゲートウェイ、データベース、コンテナオーケストレーション、クラウド機能など) の幅広いポートフォリオにアクセスできます。これらのサービスにアクセスすると、組織は競合と区別される作業に集中できるようになります。

• 組織がソリューションをグローバルに展開する準備ができたら、ソリューションを世界中のクラウドインフラストラクチャにデプロイできます。

クラウドコンピューティングは、高度に管理されたインフラストラクチャを提供することで、マイクロフロントエンドをサポートします。これにより、部門横断的なチームが end-to-end 所有権を簡単に取得できます。チームは運用に関する強力な知識を持っている必要がありますが、インフラストラクチャのプロビジョニング、オペレーティングシステムの更新、ネットワークなどの手動タスクは面倒な作業になります。

マイクロフロントエンドは制限されたコンテキストで動作するため、チームはそれらを実行するのに最適なサービスを選択できます。例えば、チームはコンピューティング用にクラウド関数とコンテナから選択でき、さまざまな種類の SQL データベースと NoSQL データベース、またはインメモリキャッシュを選択できます。チームは、サーバーレスインフラストラクチャ用に事前設定された構成要素が付属している AWS Amplifyなどの高度に統合されたツールキットでマイクロフロントエンドを構築することもできます。