アーキテクチャと状態管理

アプリの設計で一番大事なのは、状態（画面に何を出すか）をどこに置き、どう変えるかを決めることです。今の主流は単方向データフローで、「操作 → 状態を変える → 状態から画面を描く」と一方向にだけ流します。画面が状態を直接書き換えないので、「なぜこの表示になったか」を追いやすくなります。

MVVM・MVI などの形の違い、状態の置き場所は、この後のトピックで扱います。

単方向データフローを実現する形はいくつかあり、違いは状態をどうまとめ、操作をどう処理するかです。

実際は、MVVM で UiState を1つのデータクラスにまとめる「MVI 寄りの MVVM」が多く使われています。

面接で「どれを選んだか」を聞かれたら、名前よりも「チームの人数・アプリの大きさ・テストのしやすさ」で選んだ理由を話します。

画面の状態は、ばらばらの変数（isLoading・items・error）で持つと「読み込み中なのにエラーも出ている」のようなありえない組み合わせが起きます。そこでありうる状態だけを型で表します。

sealed interface UiState {          // Kotlin（Swift なら enum）
  data object Loading : UiState
  data class Success(val items: List<Item>) : UiState
  data object Empty : UiState
  data class Error(val message: String) : UiState
}

デザイナーと話すときも、「読み込み中・空・エラーの画面はどうしますか」と4つの状態で確かめると、作り漏れが減ります。

状態をどこに置くかは、誰が読むかとどれだけ長く残したいかで決めます。

よくある失敗は、同じデータを ViewModel と画面と DB にそれぞれ持ってずれることです。「正しい値はどこにあるか（Single Source of Truth）」を1か所に決め、オフライン対応するアプリなら DB を正にして、API の結果は DB に入れてから画面に流します。

オフラインファーストと同期

アプリのコードは、大きくUI・Domain・Dataの3つのレイヤーに分けると整理しやすくなります。Android の公式のアーキテクチャガイドもこの形を勧めています。

Repository の役割は、画面から「どこから取ったか」を隠すことです。ViewModel は「メモの一覧をください」と頼むだけで、それが DB からか API からかを知りません。こうすると、オフライン対応やキャッシュの方針を変えても画面のコードは変わらず、テストでは Repository を偽物に差し替えられます。

Domain レイヤーは、小さなアプリでは置かなくてかまいません。ViewModel が重くなったり、同じ処理を複数の画面で書いていたりしたら、UseCase に切り出します。

通信や DB のエラーをそのまま画面に出すと、「HTTP 503」のように利用者には意味の分からない表示になります。エラーは層ごとに意味のある種類に変えて上に渡します。

Kotlin では Result や sealed クラス、Swift では throws と独自の Error の enum でこの種類を表します。catch して何もしない書き方は、問題が見えなくなるのでレビューで止めます。

何年も続くアプリには、UIKit や View（XML）で書かれた画面、古い設計のコードが必ず残っています。全部を一度に書き直すと、その間は新しい機能が出せず、不具合も増えます。そこで少しずつ置き換えるのが現実的です。

順番は、変更が多い画面や新しく作る画面からにします。触らない画面を書き直しても、利用者にもチームにも得がありません。置き換える前に、その画面のふるまいを確かめるテスト（スナップショットや UI テスト）を足しておくと、安心して進められます。

アプリが大きくなると、1つのモジュールに全部を入れたままではビルドが遅くなり、どこがどこに依存しているか分からなくなります。そこでコードをモジュール（Android なら Gradle のモジュール、iOS なら Swift Package など）に分けます。

分け方

機能どうしの画面遷移は、app が間に入るか、遷移先を表すインターフェースだけを共通のモジュールに置いてつなぎます。変更したモジュールとそれに依存するものだけがビルドし直されるので、ビルドが速くなり、担当の範囲もはっきりします。最初から細かく分けすぎると手間ばかり増えるので、ビルド時間や人数が増えてきたら分けるくらいで十分です。

依存性注入（DI）は、クラスが使う部品を自分で作らず、外から渡してもらう書き方です。

DI は、クラスが使う部品（API クライアント・Repository など）を自分で作らず、外から渡してもらう書き方です。テストのときに本物の通信を偽物に差し替えられるのが一番の利点です。

• Android：Hilt（Dagger をもとにした Google 推奨の仕組み）が定番です。@HiltViewModel と @Inject constructor で ViewModel に Repository を渡せ、つながっていない依存はコンパイル時にエラーになります。手軽さを重視して Koin を使うチームもあります。
• iOS：決まった公式の仕組みはなく、初期化の引数で渡す（イニシャライザー注入）のが基本です。数が増えたら、依存をまとめて差し替えられるライブラリを使うこともあります。

DI の仕組みを入れるかどうかより、「作る場所」と「使う場所」を分けることが本質です。小さなアプリなら、起動時に手で組み立てて渡すだけでも十分に効果があります。