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

UI 構造スタイル系

✅ 概要​

この系統は、UI とドメイン／アプリケーションロジックの間をどのように分割し、やりとりさせるか を扱うスタイル群を対象とする。

  • 画面（View）・状態（ViewModel / Presenter / Model）・イベント（Controller / Update）の責務分担
  • どこに画面ロジックを書くか
  • どこまでを UI 側で持ち、どこからをドメイン側に任せるか

代表的なスタイル：

✅ なぜこの系統が生まれたか（歴史・背景）​

  • 画面ロジック・状態管理・ビジネスロジックが 1 ファイルに混ざると保守不能になる
  • GUI アプリケーションの登場により、イベント駆動の構造が必要になった
  • Web フロントエンドの複雑化（SPA, 双方向バインディング）によって、 UI 側だけで完結しないロジックが増えた

その結果、

「UI とそれ以外をどう分けるか」

という問題に対して、様々なスタイルが提案されてきた。

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

UI 系スタイルは主に次をターゲットにしている：

  • 画面の状態管理がスパゲッティ化する
  • イベントハンドラにビジネスロジックが直接書かれる
  • テストが難しい（UI フレームワーク依存）
  • UI の変更がその他のロジックを壊しやすい

MVC → MVP → MVVM → MVU と進むにつれ、

  • UI フレームワークからロジックを切り離す
  • 宣言的 UI / データバインディングとの相性を高める

といった方向で進化していった。

✅ この系統に属するスタイル​

  • MVC：最古参の UI 構造パターン。Model / View / Controller に分割
  • MVP：Presenter が画面ロジックを担当し、テスト容易性を高める
  • MVVM：ViewModel を用いて状態と振る舞いを束ね、データバインディングを前提にしたスタイル
  • MVU：状態 + メッセージ + 更新関数のループで UI を表現する、関数型的スタイル

✅ 他の系統との関係​

  • Layered / Domain Model 系 の中の「Presentation 層」の内部構造として使われることが多い
  • Reactive / Flow 系 と組み合わせて、イベントストリームやリアクティブな UI を構築することもある

✅ どんな時に参考になるか​

  • UI 側のコードが肥大化・スパゲッティ化しているとき
  • テスト可能な UI 構造を検討したいとき
  • Web / モバイル / デスクトップなど、UI フレームワークをまたいだ設計を考えたいとき

この系統のスタイルは、「表示」と「状態／ロジック」の境界をどこに引くか を考える上での、重要な比較対象となる。