エンタープライズ フロントエンドアプリケーション アーキテクチャ

• コードベースが大きくなるということ = 理解も修正も難しくなるということ

• 解決方法は？ コードベースを小さく保てばよい。

• ドメインごとのコードベース分離 & マイクロフロントエンドが解決策に！

• モノレポ内でのライブラリの依存関係設定 & 依存性確認などのニーズは Nx の導入で解決

• コードをアプリケーションとライブラリに分離

• アプリケーションは依存性および設定注入の役割

• ライブラリに機能の大半を実装

  • ライブラリには汎用的に使えるデザインシステム、国際化、サードパーティーモジュールだけでなく、ホームページのヒーローバナー、商品詳細ページ、注文履歴など、再利用しないコードまで記述。

Feature ライブラリ

• 基本的に、1つのページで使われるすべてのコンポーネントは同名の Feature ライブラリに記述

  • 例) account ドメインの SignInPage ページのすべてのコンポーネントは account/feature-sign-in ライブラリに記述

• 同じドメインの2つ以上のページで共有するコンポーネントは、そのドメイン内の別の feature として分離

  • 例) account ドメインの SignInPage と SignUpPage で KakaoLoginButton コンポーネントを共通利用するなら、そのコンポーネントは account/feature-social-login ライブラリに記述

• 異なるドメインのページ間で共有するコンポーネントは、共通ドメイン内の別の feature として分離

  • 例) landing ドメインの HomePage と classroom ドメインの LecturePage で共有する GlobalNavigation コンポーネントは shared/feature-navigation ライブラリに記述

Shell ライブラリ

• Feature、UI ライブラリのコンポーネントを組み合わせてページを作成

  • 例) SignInPage コンポーネントは account/shell-kr-web ライブラリのコンポーネント。ここには SignUpPage、PhoneVerificationPage などがある。

• Shell ライブラリは、アプリケーションに提供される特定ドメインのエントリーポイント

• アプリケーションごとに異なるエントリーポイントを提供できる

  • 例えば..

  • HomePage コンポーネントで使うコンポーネントは landing/feature-home ライブラリに記述されている。

  • しかし同じ HomePage でも、米国サイトの HomePage なのか、日本サイトの HomePage なのか、韓国サイトの HomePage なのかによって構成は異なるはず。

  • したがって、landing ドメインにアクセスする各アプリケーション向けの shell ライブラリを作成できる。(shell-us-web, shell-jp-web, shell-kr-web)

Provider ライブラリ

• 2つ以上の Feature ライブラリで共有する状態を管理するライブラリ

  • 例) ログイン状態を管理する shared/provider-auth-state

UI ライブラリ

• 2つ以上のライブラリで共有する Presentational コンポーネントの集合。

Utility ライブラリ

• 上記4分類に該当しないすべてのモジュール

• CLASS101 のドメインモデルとは無関係に、テストおよびデプロイが可能なレベルで独立した機能を提供する必要がある。

  • 例) shared/utils-apollo-client, shared/utils-i18n

アプリケーション

• 設定および依存性管理の役割だけを担うようになる = アプリケーションのコードはほとんどない