モノリシック フロントエンドから Next.js マルチゾーン アーキテクチャへの移行 (Nextjs)

参考メモ

このシリーズでは、実際の生産システムで得られたエンジニアリング経験に基づいた意思決定と設計アプローチを共有します。非公開のソース コード、顧客データ、インフラストラクチャ構成、内部運用情報は含まれません。例は、守秘義務に従って一般化または匿名化されています。

冒頭の問題

モノリシック フロントエンドは悪いスタートではありません。単一のチームは、共通の配送リズムと限られた製品表面積に対して、運用コストを最小限に抑えます。所得;これは、カタログ、検索、カート、チェックアウト、アカウント、販売者のエクスペリエンスが同じコード ベース内で異なる割合で変化し始めるときに発生します。```text Tek frontend → ortak derleme kuyruğu → ortak release penceresi → ilgisiz değişikliklerin birbirini beklemesi

İş alanları → farklı değişim ritimleri → farklı hata etkileri → farklı ölçek ihtiyaçları

## 最初に説明した概念```text
📦 Zone
Belirli bir URL alanından ve kullanıcı niyetinden sorumlu, bağımsız dağıtılabilen istemci uygulaması.

📦 Gateway
Tarayıcının tek bir alan adı altında gördüğü giriş katmanı; isteği doğru zone'a iletir.

📦 Independent deployment
Bir alanın değişikliğini, ilgisiz alanların release penceresine bağlamadan canlıya alma disiplini.

📦 Blast radius
Bir hata veya değişikliğin etkileyebileceği kullanıcı ve sistem alanı.
```ゾーンは単にフォルダーを区切るだけではありません。また、所有権、展開、可観測性、ロールバックの決定も分離されます。したがって、技術的な限界があります。製品の意図とチームの責任を併せて作成する必要があります。

## 問題: ある日突然モノリスの速度が低下するのはなぜですか?

マーケットプレイスが成長するにつれて、各エリアが独自のリズムを生み出します。検索チームはフィルタリングとインデックスの動作を頻繁に変更します。カート側と支払い側には、より高い信頼性とより制御されたリリースが必要です。ベンダー ツールは、顧客エクスペリエンスに関係なく提供可能である必要があります。これらすべてを同じデプロイユニットに配置することはコード共有ではありません。調整は共有を生み出します。```text
Katalog değişikliği ─┐
Arama deneyi       ├─ aynı build ve release kuyruğu
Ödeme düzeltmesi   ┘
```問題はファイルの数ではありません。ビジネスの 1 つの領域におけるリスクが、別の領域での提供のペースを決定します。

## 代替案: 事前決定オプション

|代替案 |強さ |承認された価格 |
| --- | --- | --- |
|単一のアプリケーション |最も単純なローカル開発 |共同リリースと成長領域 |
|モジュールフェデレーション |ランタイムモジュールの共有 |バージョン、実行時の依存関係、およびデバッグのコスト |
| Next.js マルチゾーン | URL フィールドごとに個別にデプロイ |ルーティング、資産、クロスゾーンの契約規律 |
|完全に分離されたドメイン |強力な絶縁 |ユーザー エクスペリエンス、セッション、SEO の断片化 |

マルチゾーンの決定は、モジュール共有の必要性によるものではありません。これは、独立した変更と単一のユーザー サーフェスの同時必要性から生じます。ブラウザには 1 つの製品だけが表示されます。チームはクライアントの責任分野を明確に認識しています。

## 決定: URL 制限をジョブ制限にマップする

各ゾーンは、URL フィールド、そのユーザー意図、およびリリース責任を所有します。ゲートウェイは、適切なリクエストを適切なアプリケーションに送信するだけのコンポーネントではありません。システムが外部から一つの製品として見える境界線です。```text
Browser
  → Gateway
    → Catalog zone
    → Search zone
    → Cart and checkout zone
    → Account zone

Her zone
  → kendi deploy kararı
  → kendi health sinyali
  → açık route sözleşmesi
```ルートの所有権は単一のレコードに保存する必要があります。そうしないと、2 つのゾーンが同じ URL を所有することになり、ロケールの動作が分岐したり、リダイレクト チェーンが目に見えないほど大きくなったりします。 URL 一致検索の平均コストは O(1) ですが、実際のコストは実行時の不確実性です。だからこそ、ルート契約をテストする必要があるのです。

## トレードオフ: 独立性は無料ではありません

マルチゾーン。これは、より多くのリポジトリを開いたり、各ページを別のアプリケーションに移動したりすることではありません。それぞれの新しいゾーン。ビルド、デプロイ、ヘルスチェック、ロールバック、セキュリティポリシー、所有コストが追加されます。クロスゾーン状態では、単一のグローバル クライアント ストアに依存するのではなく、サーバー リソースを権限として受け入れる明確な契約が必要です。

たとえば、カート カウンター、セッション更新、または言語設定をゾーン間で表示したい場合があります。このデータに対する正しい質問は、それをどのパッケージに保存するかということではありません。ソースが誰であるか、アップデートがいつ有効であるとみなされるか、エラーが発生した場合の回復方法。

## 本番環境に現実の緊張が生じている

1. **資産の分離:** 各ゾーンは独自のバンドルを作成します。静的ファイル アドレスとキャッシュ ポリシーは、競合が発生しないように設計する必要があります。
2. **ルーティングとロケール:** ゲートウェイは、単一のコントラクトを通じて動的パスと言語プレフィックスを転送する必要があります。
3. **セッション:** 認証では、ブラウザーで断片的なエクスペリエンスが生成されるべきではありません。トークンの更新とログアウトの動作はゾーン境界でテストする必要があります。
4. **ロールバック:** 独立したデプロイには独立したロールバックが必要です。ゾーンのバージョンがロールバックされる場合、ルートと API 契約のコンプライアンスを維持する必要があります。
5. **可観測性:** ユーザーリクエストが複数のゾーンを通過する場合、相関 ID、エラー率、およびルートレベルのメトリクスが表示される必要があります。

## 今日デザインし直したらもっと早く小さなゾーンを生成しなかったでしょう。私はまず、ルートの所有権、チームの独立性、および測定可能なリリースの摩擦を証明します。私なら、共有 UI、認証、タイプ、およびユーティリティのパッケージを狭くし、バージョン管理できるようにします。共有パッケージが利便性のために無制限の共有領域になると、新しいモノリスが生成されます。

最初のターゲットはせいぜいゾーンではありません。調整コストが最も低くなります。

## よく混同される```text
❌ Multi-Zone = her sayfa için ayrı uygulama
✓ Zone, bağımsız değişen bir kullanıcı niyeti ve sahiplik sınırıdır.

❌ Multi-Zone = otomatik micro frontend başarısı
✓ Route, asset, session ve rollback sözleşmeleri bilinçli tasarlanmalıdır.

❌ Shared package = her şeyi ortaklaştırmak
✓ Shared package, stabil ve gerçekten ortak olan contract'lar içindir.

❌ Bağımsız deploy = koordinasyonsuz deploy
✓ Bağımsızlık, açık contract ve daha iyi operasyon disiplini ister.

意思決定チェックリスト

1. このドメインのユーザーの意図、所有者、リリースのリズムは他のドメインと本当に異なりますか?
2. エラーが発生すると爆発範囲は縮小しますか?
3. ゾーンのルート、ロケール、および資産の制限は明確ですか?
4. セッションおよびクロスゾーン状態の権限のソースは明確ですか?
5. 各ゾーンにはロールバック、健全性、可観測性の信号がありますか?
6. モジュールフェデレーションまたはモジュールモノリスに対するこの決定のコストは明確に文書化されていますか?

制限には展開時間だけが含まれません。テストは、インシデントと意思決定のコストを削減する場合に価値があります。

この記事で覚えておくべきこと

マルチゾーンの目的は、フロントエンドを断片化することではありません。変更による影響を適切な範囲に限定することです。

モノリスは長い間正しい選択かもしれません。分解は、独立した変更、エラーの分離、および制御された配信の必要性が同時に実証された場合にのみ意味を持ちます。

次のセクション: モジュール フェデレーションを使用しない理由 で、代替の決定について詳しく説明します。