マイクロサービスの最悪の結果は**「分散モノリス」**です：物理的には分離されたサービスだが、非常に強く結合しているため一緒にデプロイする必要があります — 分散のすべてのコストを得ながら、独立性はまったく得られません。
✗ Changing one service forces redeploying several others
✗ Services share a database / shared schema
✗ A single request fans out through many synchronous hops
✗ Releases must be coordinated across teams
→ you pay network + ops cost but lost independent deployability
| アンチパターン | 問題 |
|---|
| Shared database | サービスを再結合; スキーマを独立して変更できない |
| Chatty services | リクエスト当たり多数の同期呼び出し → レイテンシ、脆弱性 |
| Nano-services | 粒度が細かすぎる; オーバーヘッドがロジックを上回る |
| No API versioning | 1つの変更がすべてのコンシューマーを破壊 |
| Synchronous chains | レイテンシと障害が A→B→C→D に沿って乗算 |
| God service | 全員が依存する1つのサービス（新しいモノリス） |
通常は境界の誤り。技術層またはエンティティで分割されたサービス（ビジネス能力ではなく）は、chatty で相互依存的になります。
bad: User-svc, Product-svc, Cart-svc all called for one checkout
good: Checkout owns the capability end to end
分散モノリスは本物のモノリスより厳密に悪い — より遅く、デバッグが難しく、運用が多いのに、やはり独立してデプロイできない。
ほとんどのアンチパターンは境界と共有データベースに遡るため、bounded context とデータ所有権を正しく得ることが、役立つマイクロサービスと害をもたらすものを区別するものです。