メインコンテンツまでスキップ

🧩 Big Ball of Mud（泥団子アーキテクチャ）

✅ このスタイルの概要​

構造が崩壊し、場当たり的な実装が積み重なった結果できあがる巨大なスパゲッティ構造。
ソフトウェアアーキテクチャにおける代表的なアンチパターン。

✅ 解決しようとした問題​

実は Big Ball of Mud は 問題を解決するために設計されたものではなく、状況の必然で生まれる構造である。

典型的な背景には以下がある：

  • とにかく早く動くものを作る必要がある
  • 設計よりも実装が優先される文化
  • チーム間の調整がなく、誰でもコードをどこにでも書ける
  • 設計者不在、もしくは設計ルールが守られない
  • 機能追加が場当たり的で、リファクタリングが追いつかない

✅ 基本思想・特徴（＝アンチパターンの兆候）​

Big Ball of Mud には以下の特徴がある：

  • 責務が曖昧：ビジネスロジック・データアクセス・UI が絡み合う
  • 依存関係が混乱：モジュール間の依存方向が統一されていない
  • 重複コードの爆発：コピー＆ペーストが頻発
  • 変更が困難：小さな修正で別の場所が壊れる
  • 新規開発が恐怖：既存構造を壊さずに機能を追加する手段がない
  • テスト不可能：テスト単位が巨大 or 密結合すぎて書けない

✅ 得意なアプリケーション​

“得意” というより、成立してしまう状況がある：

  • 超小規模な一発スクリプト
  • 数日で捨てることが確定しているコード
  • 1 人の開発者だけで動く簡易ツール

❌ 不向きなケース​

ほぼすべての長期運用プロダクトで不向き：

  • 中〜大規模システム
  • 仕様変更が頻繁に発生するアプリ
  • チーム開発が継続するプロダクト
  • 品質や可観測性が必要なプロダクト
  • 複数 UI・複数サービスから利用されるドメインを持つ場合

✅ 歴史（系譜・親スタイル）​

  • ソフトウェアアーキテクチャの黎明期に“自然発生的に”生まれた原始形態
  • Fowler や他の著者によりアンチパターンとして整理された
  • その後、レイヤードアーキテクチャや DDD などが “脱 Big Ball” を目指して発展していった

✅ 関連スタイル​

✅ まとめ​

Big Ball of Mud は「悪いコードの書き方」ではなく、
設計が成り立たなかった状況を可視化した結果としての構造 である。

このスタイルを理解することは、
モダンアーキテクチャ（Layered / DDD / Hexagonal）が
なぜ存在し、何を解決しようとしたのかを理解するための土台になる。