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

設計: 基礎(関心の分離・責務・凝集と結合)

knowledge所要 25分最新草稿
→次: API設計: REST の基礎(リソース・メソッド・ステータス・契約)次: 設計: アプリの構成(レイヤ分割・FE/BE/DBの責務)
意味グラフ(この教材と内容的に近い教材・1ネスト)
例え(Analogies)
設計=部署と業務分掌

会社で「誰が何を担当するか」を決める業務分掌。役割が明確なら、誰かが抹けても他に影響が波及しにくい。凝集=関連業務を同じ部署に、結合=部署間の依存を最小に。

概要

📍 設計 ▸ 設計基礎 ▸ 基礎 | 種別: knowledge | facts_as_of 2026-06

公式ドキュメント — knowledge

🎞 スライド

良い設計=「変更に強い」

動くだけでなく、後から直しやすく

関心の分離(before → after)

before: [ 画面+検証+DB が1か所 ] ← 変更が怖い
│ 分ける
after: [画面] ─ [入力検証] ─ [DBアクセス] ← 変更が1か所に閉じる

原則

高凝集(関連は集める)/低結合(依存は減らす)/単一責任/DRY

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

ソフトウェア設計一般 ; 2026-06確認

確認問題(Review-Questions)
単一責任の原則とは?択一
基礎公式
解答・解説▾ 開く

一つのモジュールは一つの責務だけを持つべきという原則。

高凝集・低結合とは?記述
基礎公式
解答・解説▾ 開く

関連するものは集め(凝集)、モジュール間の依存は減らす(結合)。変更に強くなる。

目次
例え概要公式ドキュメント出典確認問題
鮮度
最新
更新: 2026-06-15
次回棚卸し: 2028-06-15
周期: 24か月
版: 設計一般概念

概要

良い設計は変更に強い。関心の分離(役割で分ける)・単一責任(一つのものは一つの仕事)・高凝集・低結合(関連は集め、依存は減らす)。

現場あるある(なぜ効くか)

1ファイル500行の**“神クラス”**で変更が怖い。画面処理とDBアクセスが混ざり、UI変更でDBが壊れる。→ 分けてあれば変更は1か所で済む。

公式ドキュメント準拠

  • 関心の分離 / 単一責任。凝集(関連を集める)と結合(依存を減らす)。
  • DRY(重複を避ける)・抽象化(詳細を隠す)。設計は将来の変更コストへの投資。

出典: ソフトウェア設計の一般原則。

🧭 誤解訂正集

よくある誤解 正しい理解
動けば設計は不要 変更コストが跳ね上がる
分割するほど良い 過分割も害(凝集を見る)

📖 用語

  • 関心の分離 … 役割ごとに分けて持つ。
  • 単一責任 … 1つのものは1つの仕事。
  • 凝集 / 結合 … 関連の集まり具合 / 依存の多さ。
  • DRY … 重複を避ける(Don't Repeat Yourself)。
  • 抽象化 … 詳細を隠して使いやすくする。

✅ 確認の目安(can-do)

関心の分離・単一責任・凝集/結合を区別し、**「この設計のどこが変更に弱い/強いか」**を説明できる。