非構造〜初期系
✅ 概要
この系統は、ソフトウェアアーキテクチャという概念がまだ明確でなかった時代、
「とりあえず動くものを作る」 ことを中心に生まれた初期の構造スタイルを扱う。
ビジネスロジックやデータアクセス、UI の責務分離などは考慮されず、
コードはしばしばファイル間や関数間で入り乱れ、
構造化よりもスピードが優先されていました。
代表的なスタイル（またはアンチパターン）としては以下がある。
✅ なぜこの系統が生まれたか（歴史・背景）
- 小規模なプログラムやスクリプトが中心で、長期保守や拡張の必要性が低かった
- チーム開発よりも個人開発が多く、構造化の必然性がまだ弱かった
- 設計パターンやレイヤードアーキテクチャが確立される前の時代
- とにかく要件を満たす動くものを「最短」で作ることが重要だった
✅ 解決しようとした問題
初期系スタイルは、実は「解決したかった課題が多い」というより 制約条件に合わせた必然 だった。
- 設計に時間をかけられない（とにかく納期が短い）
- アプリが小規模で複雑さが低い
- 構造化よりも即時のアウトプットが求められた
結果として、のちにアンチパターンとして扱われる構造につながった面もある。
✅ この系統に属するスタイル
● Big Ball of Mud
- 設計がほぼ存在せず、機能が場当たり的に追加された状態
- 責務が入り乱れ、依存関係も混乱し、変更が極めて困難になる
- アンチパターンとして代表的
● Transaction Script
- 各処理（トランザクション）をスクリプトや関数として書き並べる
- 小規模では有効だが、複雑化すると重複やロジック分散が急増する
- Fowler による命名で有名
✅ 他の系統との関係
- B. データ中心系（Active Record など） は Transaction Script の延長線上に発展
- C. レイヤード系 は Big Ball や Transaction Script の問題を解決するために登場
- 全ての構造スタイルの“原始形態” として理解できる
✅ どんな時に参考になるか
- 小さなスクリプトや一時的なツールを作るとき
- アンチパターンを避けるための「悪い例」
- なぜレイヤードや DDD、Hexagonal が必要とされるのかを理解する土台として