Ceeds Academy教材アプリ教材・症状語・タグで検索
索引グラフ試す
設計▸設計基礎

設計: アプリの構成(レイヤ分割・FE/BE/DBの責務)

knowledge所要 25分最新草稿
前提: 設計: 基礎(関心の分離・責務・凝集と結合)
意味グラフ(この教材と内容的に近い教材・1ネスト)
例え(Analogies)
アーキテクチャ=建物の階層と動線

受付(UI)・事務(ロジック)・倉庫(DB)を階で分け、動線(依存)を一方向に整える。全部を一部屋に詰めると、模様替えのたびに全体が混乱する。

概要

📍 設計 ▸ 設計基礎 ▸ アプリの構成 | 種別: knowledge | facts_as_of 2026-06

公式ドキュメント — knowledge

🎞 スライド

アプリの構成=「責務でレイヤ分割」

表示・ロジック・データを分け、依存は一方向

3層と依存の向き(テキスト図)

[表示層 (Next/React)] UIを描く
│ 依存は下向き
▼
[ロジック層 (FastAPI)] 権限・イベント・ドメイン
│
▼
[データ層 (DB/Cosmos)] 保存・取得

ポイント

依存は上→下の一方向 / 各層を差し替え可能に(例: ContentSource 抽象)

—
クリックで一覧(遷移しない)
出典(sources)

レイヤードアーキテクチャ一般 ; 2026-06確認

確認問題(Review-Questions)
Ceedsで表示とNotion取得を担うのは?択一
基礎公式
解答・解説▾ 開く

Next(FE)。権限/データはFastAPI(BE)。

レイヤード設計で依存の向きは?記述
基礎公式
解答・解説▾ 開く

一方向(表示→ロジック→データ)に揃える。

目次
例え概要公式ドキュメント出典確認問題
鮮度
最新
更新: 2026-06-15
次回棚卸し: 2028-06-15
周期: 24か月
版: アーキテクチャ一般
FE/BE/DBの責務と依存の向きを1枚で
FE/BE/DBの責務と依存の向きを1枚で

概要

アプリは責務でレイヤ分割する。表示(UI) / ロジック / データ(DB)。それぞれの責務を明確にし、**依存の向きを一方向(上→下)**に揃えると、差し替えや変更がしやすい。

公式ドキュメント準拠

  • レイヤード:表示層(Next/React)→ アプリ/ドメイン層(ロジック)→ データ層(DB)。
  • 依存は一方向に(上→下)。関心を分け、差し替え可能に(例: ContentSource 抽象)。
  • Ceeds例:Next(表示+Notion取得)/ FastAPI(権限・イベント)/ Cosmos(データ)。

出典: レイヤードアーキテクチャの一般。

🧭 誤解訂正集

よくある誤解 正しい理解
1ファイルに全部 変更が波及する(責務で分ける)
レイヤを増やすほど良い 必要十分に(過剰は複雑化)

📖 用語

  • レイヤード(層) … 表示・ロジック・データなど責務ごとの段。
  • 表示層 / FE … UIを描く層(Next/React)。
  • ロジック層 / BE … 権限・イベント・ドメイン処理の層(FastAPI 等)。
  • データ層 / DB … 保存・取得を担う層(Cosmos 等)。
  • 依存の向き … どの層がどの層を呼ぶか。一方向(上→下)に揃える。
  • 抽象(差し替え可能) … 実装を隠し交換できる境界(例: ContentSource)。

✅ 確認の目安(can-do)

表示/ロジック/データの責務と依存の向きを区別し、**「この機能はどの層に置くか・依存は正しい向きか」**を判断できる。