アプリ設計の正体 ― なぜ分ける？なぜ面倒？を直観で理解する

🧩 1. アプリ開発って、実は「レゴ」じゃなくて「街づくり」

「アプリ作って」と聞くと、
多くの人は レゴみたいに部品を積んでいけばできると思っている。

でも実際はぜんぜん違う。

アプリはレゴではなく、街です。

• 交通ルールがある
• 下水管や配電盤（インフラ）がある
• 店舗やビル（UI）がある
• 物流（データフロー）がある
• 住民（ユーザー）が勝手に動く
• しかも全部 24 時間止められない

だから「一箇所壊れるだけで街全体が混乱する」。

アプリ設計とは何か？

👉 街全体が壊れないように “責任範囲” を分ける作業
これが分かると、下の話が全部つながる。

---

🏢 2. なぜレイヤーで分けるのか？ → “壁” がない街は地獄だから

アプリには “レイヤー” という考え方がある。

• UI
• ドメイン（アプリが頑張りたい本質）
• データ
• インフラ（Android や WebViewなど）

これ、実はただの階層分けじゃなくて……

👉 街の「区画整理」 です。

🔥 壁のない街を想像してみて

• 下水管（データ）がむき出し
• 電線（通知サービス）が部屋の中を通っている
• 部屋（UI）から土木工事が始まる
• 市役所（ドメイン）が電柱の仕様を直接いじっている

もう地獄。

一箇所変えると全部に波及し、
誰がどこを触っても 事故る構造 になってしまう。

だから設計ではこうする：

👉

• UIは「人と話す」だけ
• ドメインは「街のルール」を守るだけ
• データは「倉庫管理」をするだけ
• インフラは「管轄するだけ」

たったこれだけで街は壊れにくくなる。

---

💬 3. Repository / Use Case / Config … 何のため？

専門用語が出てくるたびに
「なんでそんなもの作るの？」
と思う人が多い。

全部、直観的に言えばこう。

---

🏛 Repository（リポジトリ） → “倉庫番のおじさん”

倉庫にはいろんな入り口がある：

• トラック（通知サービス）
• 船（Web API）
• 徒歩（端末のローカルストレージ）

Repository は言う：

倉庫の入り口は気にするな。
私が全部仕分けしておくから、必要なものだけ渡すよ。

UI はどこから来たデータか知らなくていい。

「倉庫のおじさんに聞けば全部出てくる」

これが Repository。

---

🎮 Use Case → “市役所の手続き窓口”

市役所には「住民票を出す窓口」があり、
そこに行けば一通りの手続きが終わる。

Use Case とは：

“やりたいこと” を一つだけ確実にこなす窓口

• 「この通知をチャンネルに紐付けたい」
• 「ランキング済のチャンネルリストが欲しい」

全部「窓口仕事」なんです。

窓口に頼めば UI 側は楽になり、
ビジネスルール（ドメイン）も整理される。

---

⚙️ Config → “市役所が使う地図帳”

アプリには「決まり文句」が山ほどある。

• パッケージ名
• Uniform Resource Locator
• DataStore 名
• ファイル名
• 重みのデフォルト値

これをコードに散乱させると一瞬で崩壊する。

Config は言う：

地図帳（設定値）は全部ここにまとめてるよ。
どこの部署もこれを参照してね。

---

🧠 4. なぜドメインは汚さない？ → “市長は配管を触らない”

街の運営（ドメイン）は、

• WebView
• NotificationListenerService
• DataStore
• Android SDK

を知らなくていい。

理由は明快：

👉 市長は配管を触らないから。

配管を変えたら街全体が止まる。
市長の仕事は町のルールを決めることであり、
水道の形状変更ではない。

ドメインがシンプルであるほど

• テストしやすい
• 変更に強い
• バグりにくい

＝壊れない街になる。

---

🔄 5. 一方向データフロー → “物流は逆走させない”

データがあっちこっちで更新される街は壊れる。

UI → Domain → Repository → DataStore → Flow → UI

この 一方向の物流ルート を守ると世界は劇的に安定する。

双方向は混乱の元。

• UI が直接ストレージを書き始める
• ドメインが Service を直接呼ぶ
• DataStore が UI を再描画しようとする

全部アウト。

物流は常に「一方向」。
逆走は事故。

もしアプリがなぜか “突然バグる” のは、
ほとんどが この物流が破綻しているのが原因。

---

🌐 6. WebView と JavaScript ブリッジ → “通訳の仕事”

Native（Kotlin） と JavaScript（Web 内部）は
互いに理解できない。

だから必要なのは通訳。

Kotlin → JS

「検索クエリこれ！」

JS → Kotlin

「投稿あったよ！」
「今の Uniform Resource Locator これだよ！」

この “翻訳ポイント” を数個の API に固定することが、
クリーンな WebView 連携のコツ。

通訳にはこう言う：

“あなたの仕事は翻訳だけ。
相手の国の政治（ロジック）に手を出さないで。”

---

📊 7. ランキングロジックは「純粋関数」にする → “計算は計算だけでいい”

ランキングは数式。

UI がどうとか、保存先がどうとか、一切関係ない。

計算は計算だけにする。
外部に影響されない “純粋な関数” にする。

すると：

• いつ呼んでも壊れない
• テストが1行で終わる
• 誤作動しない
• UI が変わっても動き続ける

これが “動かしても壊れない街” の秘密の１つ。

---

🧱 8. 全部まとめると、アプリは「街 + システム + 通訳」

ここまでを完結にまとめると：

役割	直観的なたとえ	技術の名前
UI	店舗	Compose / View
ViewModel	店長	ViewModel
Domain	市長・法律	UseCase / Entity
DataStore / Room	倉庫	Data Layer
Repository	倉庫番	Repository
WebView / Notification	配管・交通	Infrastructure
JS Bridge	通訳	Port / Adapter
Config	地図帳	Config Layer

あなたがつくるアプリは、
「街を壊さず、住民が迷子にならず、安全に暮らせるように設計する作業」 そのものなんだ。

---

🚀 9. 最後に

設計とは “コードを書く前にバグを潰す技術” である。
だから面倒ではなく、“未来の自分を守るための保険”。

アプリはレゴじゃない。
インフラと物流と条例で動く「街」だ。

バグるアプリの90%は「責任範囲の崩壊」で説明できる。

そして最後に一言：

街は一日で崩壊するが、
よい設計の街は、10年経っても壊れない。