2026.01.10

【備忘録】アーキテクチャ、設計思想、フレームワーク、ライブラリの違いが曖昧なので調べてみた。

palm

この記事の目次

概念マップ

この記事では、これらの技術を同列に比較するのではなく、
役割とレイヤの違いとして整理する。

意味：
- 「どう考えるか」
- 設計時の思考の軸・価値観
- コードや構造を直接は決めない
役割:
- 設計上の意思決定を助ける
- 複数の選択肢があるときに判断材料を与える
- チーム内で「なぜそうするのか」を共有する共通言語になる
特徴：
- 複数のアーキテクチャに同時に適用できる
例:
- ドメイン駆動設計（ドメインの理解とモデリングを中心に据え、ビジネスドメインの要件を反映）
- オブジェクト指向設計（オブジェクトをもとに現実をモデル化し、得られたモデルを元にソフトウェアを設計）
- 関数型思考（プログラム全体を入力に対して出力を返す「関数」の組み合わせで構築する考え方）
- SOLID 原則（保守性・拡張性・再利用性の高いオブジェクト指向ソフトウェアを設計するための5つの基本原則の頭文字をとったもの）

意味：
- 全体的な構造
- 基本設計（ルール、制約決定）
- 「どう作らせるか」「そう作らないといけない」
役割:
- 高い視点での構造やルールを決めること
- 構成要素がどのように連帯するか、どのように動作するかといった「骨組み」や「枠組み」を定義（ルール化）
- システム全体の品質（拡張性、保守性、効率性）を高めるために不可欠
例:
- MVC（モデル・ビュー・コントローラー）
- MVVM（モデル・ビュー・ビューモデル）
- 3層アーキテクチャ（プレゼンテーション層・アプリケーション層・データ層）
- マイクロサービスアーキテクチャ（ソフトウェアを小さく、独立して展開可能なサービスに分割）
- クリーンアーキテクチャ（懸念事項の分離と依存関係の逆転に焦点を当て、コンポーネントを明確な境界を持つ明確なレイヤーに編成）
- REST（通信の設計用。HTTPを前提に、リソース指向/ステートレス性などの制約条件を課すことで、疎結合で拡張性の高いシステム連携を実現する）

概念:
- アプリケーション開発の土台となる「骨組み」や「枠組み」を提供
- フレームワーク決定は「結婚と同じ」と言われるほど、ソフトウェアと密に結合している
役割:
- アプリケーションの制御フローを定義
- 開発者はその枠組みに沿って必要なロジックを「はめ込む」
- ゼロから開発するより大幅に工数を短縮できる
制御:
- 呼ばれる
- Inversion of Control（IoC）：フレームワークが開発者のコードを呼び出す
例:
- TensorFlow（Googleが開発。機械学習／ディープラーニングのためのFW）※ 機械学習分野ではFWと呼ばれるが、WebFWほど強制しないものも含まれる。
- Ruby on Rails（Rubyを基にWebAPIなどを効率的に開発するためのFW）
- Next.js（Reactを基に高速でSEOに強い静的サイトやWebアプリケーションを効率的に開発するFW）
- Astro（静的コンテンツ中心のWebサイトを高速かつ軽量に構築することに特化そたFW）
- Angular（Googleが開発。TypeScriptを基に1枚のページで完結する動的なWebアプリ（SPA）の構築に強みがあるフルスタックFW）
- FastAPI（高速で使いやすいAPIサーバーを構築できるFW）

➡️機能が豊富なものから、特定の用途に特化した軽量なものまで様々

概念:
- よく使われる便利な機能や処理を「部品化」
- 同じコードを何度も書く手間を省き、開発時間を短縮
- 用途に応じた多種多様なライブラリが存在
役割:
- 開発者が「この機能が欲しい」と思ったときに、自ら呼び出して利用する。
制御:
- 自分が呼ぶ
  - ライブラリは Callback などを通じて処理の一部を呼び返すことはあるが、制御フローの主導権は開発者側にある。
- 部分的な拡張、必要な瞬間だけ呼び返す
- 開発者のコードがライブラリの関数を呼び出す
例:
- numpy (数値計算)
- stdio.h（標準入出力）
- React（UI構築ライブラリ）
- Axios（HTTP通信）
- Lodash（ユーティリティ関数）

GraphQL：
- アーキテクチャ（API設計スタイル）
- APIのクエリ言語とランタイムのことで、クライアントが必要なデータを「必要な分だけ」「一度のリクエストで」取得できるように設計された技術
- バックエンドとの連携がスムーズになる
gRPC：
- アーキテクチャ（通信スタイル）＋プロトコル
- Googleが開発。オープンソースの高性能なリモートプロシージャコール（RPC）フレームワーク。
- 異なるサービスやアプリケーション間で高速かつ効率的な通信をする
- REST APIと比較でき、学習コストが高い

混合しやすい理由
- UIは全部 JSX で書くので「支配されている感じ」がする
React が「ライブラリ」である理由：
- 自分で呼ぶ
- 使う／使わないを選べる（部分的）
- アプリ全体の制御フローは握らない
Next.jsとの違い
- Next.jsは制御フロー（主導権）を握っている
- Next.jsに従わないと作れない。
- Reactは、Next.js に「呼ばれている」
- Next.js がいつ・どう描画するかを決める
- Reactは、主導権が開発者にある。Next.jsは主導権がNext.js側。