システムの形を知る
家の間取りと同じように、ソフトウェアにも「定番の間取り（アーキテクチャ）」があります。エンジニアがどのような構造でシステムを作っているかを知ることで、デザインの整合性が高まります。
MVC (Model-View-Controller)
「データ・表示・制御の分離」
概要
アプリケーションを以下の3つに分ける最も古典的なパターンです。
- Model (モデル) : データそのもの（ユーザー情報、商品データなど）
- View (ビュー) : 画面表示（UI、HTML/CSS）
- Controller (コントローラー) : ユーザーの入力を受け取り、ModelとViewを動かす司令塔
デザインへの適用
- データの状態と見た目を分ける : 「エラー状態の見た目」と「エラーという事実」を区別して考える。
- ロジックをViewに持ち込まない : 複雑な計算や判断は裏側（Controller/Model）で行い、Viewは結果を表示するだけに徹する。
Layered Architecture (レイヤーアーキテクチャ)
「層による役割分担」
概要
システムを階層（レイヤー）に分け、依存関係を一方向に整理する手法です。 一般的なWebアプリでは「プレゼンテーション層（UI）」→「ビジネスロジック層（ルール）」→「データアクセス層（DB）」のように流れます。
デザインへの適用
- UIは氷山の一角 : デザイナーが触れるUI層の下には、分厚いビジネスロジックやデータベースがあることを意識する。
- DB設計への配慮 : 画面上の項目を増やすことは、下の層（DB）の変更を伴う可能性があることを理解する。
Microservices (マイクロサービス)
「小さなサービスの集合体」
概要
巨大な1つのアプリ（モノリス）を作るのではなく、機能ごとに独立した小さなアプリ（サービス）をたくさん作り、それらを連携させる手法です。 例：ユーザー認証サービス、決済サービス、在庫管理サービスが別々に動いている。
デザインへの適用
- 体験の分断に注意 : サービスが分かれていると、画面遷移時にロードが発生したり、デザインのトーンがズレたりしやすい。
- 部分的な障害 : 「決済機能だけがダウンしている」といった状況が起こりうるため、エラー処理（部分的な利用不可表示）のデザインが重要になる。