物流業務にマイクロ フロントエンドが必要な理由は何ですか? (Why Logistics Ops Needed Micro Frontends)

単一パネル、複数チーム、単一デプロイキュー

予約、待機マップ、通知、ID が物流業務の表面に同時に存在します。これらを単一の SPA パッケージに収めることは、短期的には迅速です。しかし、チームが増えると、変更のたびにパネル全体が再公開されなければなりません。```text Ops Monolith Bundle ├─ auth screens ├─ booking pages ├─ wait map └─ notifications ↓ one build, one blast radius

## 最初に説明した概念```text
📦 Mikro Frontend
Bağımsız geliştirilip yayınlanabilen, runtime'da bir shell içinde birleşen UI dilimleri.

📦 Blast Radius
Bir değişikliğin bozabileceği yüzey alanı; tek bundle'da genelde tüm uygulama.

📦 Sahiplik Sınırı
Bir ekibin güvenle değiştirebildiği kod ve deploy birimi.

📦 Ops Surface
Operatörlerin günlük işini yaptığı yönetim panelleri bütünü.
```所有権の境界線が明確でない場合、マイクロ フロントエンドは組織的な解決策であり、一時的な流行ではありません。

## 成長が損なわれるのはどこですか

地図チームは Leaflet プラグインをテストし、予約チームは週に 2 回公開したいと考えています。これらは同じパイプライン内にロックされています。リリース ケイデンスの競合は、それがアーキテクチャの問題ではなくカレンダーの問題である場合に、アーキテクチャに問題をもたらします。

## 独立した速度と共通のアイデンティティ

ユーザーは単一のセッションを要求します。チームは独立したスピードを求めています。解決策は、アイデンティティを共有しながらフィーチャ サーフェスを分離することです。```text
Shared Auth Contract
   ↓
Feature Remote A   Feature Remote B
```## まだ早いうちは

2 ページの IA では MFE コストが高くなります。対象: 複数のチーム、異なるブロードキャスト リズム、ネットに限定されたコンテキスト。

## このエピソードで最も混乱を招く対戦```text
❌ Mikro frontend = daha fazla React uygulaması kopyalamak
✓ Mikro frontend = runtime'da birleşen, sözleşmeli sahiplik sınırları

❌ Tek repo = tek deploy birimi zorunlu
✓ Monorepo olabilir; runtime ve pipeline ayrımı asıl karardır

❌ Ops paneli hep monolit kalmalı
✓ Ops büyüdükçe monolit yanında remote estate gerekir

独自のシステムのチェックリスト

1. 同じ ops バンドルを公開しているチームは何チームありますか?
2. 過去 3 つのホットフィックスはどのサーフェスに影響しましたか?誰が待っていましたか?
3. 認証が変更されたときにどのアプリケーションが再構築されましたか?
4. 機能フラグ、それとも本当に個別に導入する必要がありますか?
5. 爆発範囲を図に描いてもらえますか?

このセクションで覚えておくべきこと

1. 物流業務において、問題のほとんどはドメインではなく、公開と所有権の競合です。
2. マイクロ フロントエンドには、共通のアイデンティティと独立した機能の速度が同時に必要です。
3. 初期の MFE コストは高い。リズムが崩れたチームは合図。

1 つのパケット、1 つのキュー: 操作をスピードアップすることではなく、お互いを待たせることによってスケールします。