「Clean ArchitectureとOnion Architectureは何が違うのか」「DDDの集約はどこから学べばいいのか」「マイクロサービスの可観測性は何を読めば体系的に分かるのか」——ソフトウェアアーキテクチャを独学していると、テーマごとに「まず何を読むべきか」で毎回つまずきます。書籍は網羅的すぎて時間がかかり、断片的なブログ記事は玉石混交で、体系の地図が手元にありません。
awesome-software-architecture は、こうした設計・アーキテクチャの学習リソースを54分野・253ページにわたって厳選・整理したGitHubのキュレーションリストです。作者はMehdi Hadeli氏。約1.1万スターを集め、公式サイト awesome-architecture.com からも閲覧できます。本記事は公式リポジトリのREADMEと各ページを一次ソースに、このリストの全体像と、設計を独学する人にとっての使いどころを日本語で整理します。
この記事のポイント（30秒でわかる awesome-software-architecture）
・ソフトウェアアーキテクチャ・設計パターン・設計原則の学習リソースを54分野・253ページに整理したGitHubのキュレーションリスト。作者はMehdi Hadeli氏
・各ページは単なるリンク集ではなく、テーマごとに厳選した記事（＋動画）の束。編集者のおすすめには⭐が付く
・扱う範囲はClean/Onion/Hexagonal/Vertical Slice、DDD、CQRS、イベント駆動、マイクロサービス、設計原則、クラウドネイティブまで広い
・ライセンスはCC0-1.0（パブリックドメイン相当）。リスト自体は自由に使えるが、リンク先の各記事の条件は個別に確認が必要
・上から順に読むリストではなく「用途から引く地図」。AIそのものの解説ではないが、AI時代にも土台になる設計知識の入り口になる
同じくGitHubのキュレーションリストの歩き方は awesome-sysadminとは｜42分野・3.4万★のサーバー管理OSSをまとめた定番リスト解説 でも解説しています。あちらが「サーバーを運用するためのOSSツールの地図」なのに対し、こちらは「設計を学ぶための記事・動画の地図」で、対象が“ツール”ではなく“知識”という違いがあります。
awesome-software-architectureとは——54分野を束ねる設計学習マップ
awesome-software-architectureは、GitHubで広く使われる「Awesome List」形式のひとつです。Awesome Listとは「特定テーマについて本当に役立つリソースだけを厳選して並べたリポジトリ」の総称で、言語・フレームワーク・データセットなどあらゆる領域に存在します。そのなかでこのリストが担当するのが、ソフトウェアの設計・アーキテクチャという領域です。
決定的な特徴は、扱うのが“ツール”ではなく“学習リソース”だという点です。README上部の説明は「Curated list of awesome articles and resources to learn and practice software architecture, patterns and principles（設計を学び実践するための厳選記事・リソース集）」。つまりインストールして動かすソフトウェアの一覧ではなく、読んで理解を深めるための記事・動画へのポインタ集です。
数字も押さえておきましょう。本記事執筆時点（2026年7月）で、リポジトリは約1.1万スター・約1,000フォークを集め、コミット履歴も直近まで動いています。作者のMehdi Hadeli氏はREADMEで「自分が価値を感じ、刺激を受けたリンクを共有し、みんなで知識を高め合うために作った」と述べており、個人の学習ノートが公開されて定番リソースへ育った、という成り立ちです。
このリストの価値は「網羅」よりも「方向づけ」にあります。設計の全論文・全記事を尽くしているわけではありませんが、各分野で“まず読むべき”記事が⭐付きで並ぶため、ゼロから検索するより圧倒的に速く良質な入口へたどり着けます。リストは答えではなく、探索の出発点です。
正直に付け加えると、READMEの一行サマリー（各項目の説明文）は一部が「TODO…」のまま未整備です。実際、README上の項目説明の多くはまだ埋まっていません。ただし説明が空でも、ページ本体（例：docs/design-patterns/builder.md）には記事リンクが収録されているケースが多く、「説明は未完だが中身はある」という状態が混在しています。完成された教科書ではなく、育ち続けている生きた索引だと捉えるのが実態に近いでしょう。
全体像——54分野を6グループで俯瞰する
54分野は多く見えますが、役割でグループ化すると一気に頭に入ります。下図は主要グループと代表分野の対応です。
54分野 / 253ページ"] ROOT --> G1["アーキテクチャ様式
Clean / Onion / Hexagonal
Vertical Slice / Modular Monolith"] ROOT --> G2["ドメイン設計
DDD / CQRS
Event Driven / Event Sourcing"] ROOT --> G3["分散システム
Microservices / Messaging
Service Mesh / API Gateway"] ROOT --> G4["設計原則・パターン
SOLID / GRASP / DRY / KISS
Design Patterns / Cloud Patterns"] ROOT --> G5["クラウド・運用
Cloud Native / PaaS / IaaS
DevOps / Scaling / Caching"] ROOT --> G6["基礎・その他
OOD / Clean Code / Refactoring
Concurrency / Database / AI"]
このグルーピングは公式の分類そのものではなく、実務で「どの場面で開くか」を基準にした整理です。新規サービスの土台を決めるならG1（アーキ様式）とG2（ドメイン設計）、既存システムを分割するならG3（分散システム）、コードレビューの観点を揃えたいならG4（設計原則）、という具合に、自分のタスクから入り口を選べます。以降のセクションでは、このうち特に検索需要の高いG1〜G4を掘り下げます。
アーキテクチャ様式を学ぶ——Clean・Onion・Hexagonal・Vertical Slice
「アーキテクチャ様式」は、アプリケーションの依存関係をどう並べるかの流派です。このリストは主要な様式を独立分野として立て、それぞれに解説記事を集めています。名前が似ていて混乱しがちな4様式を、READMEの定義に沿って整理すると次の通りです。
| 様式 | 提唱者 | 中心アイデア | 向いている場面 |
|---|---|---|---|
| Clean Architecture | Robert C. Martin | Hexagonal・Onionなどを統合した同心円モデル。依存は内向きのみ | 中〜大規模で依存方向を厳格に守りたい |
| Onion Architecture | Jeffrey Palermo | ドメインを中心に据えた同心円の層構造 | ドメインモデルを外部技術から守りたい |
| Hexagonal（Ports & Adapters） | Alistair Cockburn | 入出力をPort経由でAdapterに委ねる | 外部I/Oを差し替え可能に保ちたい |
| Vertical Slice | — | 層でなく機能（スライス）単位で分割 | 機能追加のたびに全層を触る負担を減らしたい |
4つは対立概念というより、「依存を内側（ドメイン）に向ける」という同じ思想の別実装です。Clean ArchitectureはREADMEでも「HexagonalやOnionなど多くのガイドラインから派生したもの」と説明されており、Onion／Hexagonalの上位互換的な位置づけで語られます。一方、Vertical Sliceは層を横断して「機能ごとに縦切り」する発想で、CQRSと相性がよく、近年のマイクロサービス／モジュラーモノリスの文脈でよく登場します。
・まず1つ選ぶなら、依存方向のルールが明快なClean Architectureの記事から入るのが定番
・Onion／Hexagonalは「同じ思想の別の言い方」として並べて読むと理解が速い
・機能追加のたびに全層を触るのが辛くなってきたらVertical Sliceを検討する
このリストのModular Monolith（モジュラーモノリス）分野も合わせて読む価値があります。READMEは「モノリスとマイクロサービスの利点を組み合わせ、単一コードベース・単一DBを保ちつつモジュール単位で独立開発・デプロイできるようにする設計」と説明しており、いきなりマイクロサービスに飛ばない現実的な選択肢として近年注目されています。
DDD（ドメイン駆動設計）を学ぶ——19の中核概念で「モデリング」を鍛える
このリストで最も充実している分野のひとつがDDD（Domain-Driven Design）です。単一の「DDDとは」ページで終わらせず、19の中核概念を独立ページに分解しているのが特徴で、体系的に学びたい人に向いています。
収録される概念を大きく分けると、次の3層になります。
・戦略的設計：境界づけられたコンテキスト（Bounded Context）、戦略的設計パターン（Strategic Design Patterns）——大きく複雑なドメインを、共通言語で区切られた管理可能な単位に分割する視点
・戦術的設計：集約（Aggregation）、エンティティと値オブジェクト（Value Objects）、貧血ドメインモデル（Anemic Domain Model）と充血ドメインモデル（Rich Domain Model）、ドメインサービス、アプリケーションサービス——モデル内部の部品と、ふるまいをどこに置くかの設計
・実装の型：ドメインイベント（Domain Events）と統合イベント（Integration Events）、ドメインプリミティブ、マッピング、例外とバリデーション——モデルをコードへ落とすときの定石
たとえば「値オブジェクト」ページには20本以上の記事リンクが集まり、そのうち複数に⭐が付いています。「エンティティと値オブジェクトの違い」「値オブジェクトのより良い実装」といった、独学だと出会いにくい良質な記事へ一気に到達できるのがこのリストの強みです。
DDDは用語が多く、独学の挫折ポイントになりがちです。このリストのように「戦略／戦術／実装」で棚を分けておくと、いま自分がどの層の話をしているのかが見え、迷子になりにくくなります。まずは境界づけられたコンテキスト（全体像）と値オブジェクト（最小の部品）の2つから読むのがおすすめです。
CQRSとイベント駆動——「書き」と「読み」を分ける設計を学ぶ
CQRS（Command Query Responsibility Segregation）は、READMEで「コマンド実行（書き込み）とデータ照会（読み取り）の関心を分離し、アプリケーションモデルを読み取り用と書き込み用の2つに分ける設計パターン」と説明されます。読み書きを別モデルにすることで、それぞれを目的に最適化でき、スケーラビリティ・性能・保守性を高められる、という発想です。
CQRSはしばしばイベント駆動アーキテクチャ（Event Driven Architecture）およびイベントソーシング（Event Sourcing）とセットで語られます。イベント駆動は「疎結合なアプリケーションが、イベントブローカーを介してイベントを非同期に発行・購読する」設計で、イベントソーシングは「アプリケーションの状態変化を一連のイベントとして記録する」技法です。このリストはこれらを別分野として立てており、CQRS→イベント駆動→イベントソーシングと読み進めると、近年の分散システム設計の共通言語が身につきます。
読み書きを分けたり、状態をイベントの連なりで持ったりすると、次に立ち上がるのが「データの一貫性をどう保つか」という問題です。このリストは、そのための隣接分野もひと通り揃えています。メッセージング（Messaging）、分散トランザクション（Distributed Transactions）、分散ロック（Distributed Locking）、結果整合性（Eventual Consistency）、バックプレッシャー（Back Pressure）——いずれもマイクロサービスやイベント駆動を本気で運用するときに必ずぶつかる論点です。たとえば「複数サービスにまたがる更新を、2フェーズコミットに頼らずどうまとめるか」を考え始めたら、分散トランザクションと結果整合性のページを並べて読むと、Sagaやアウトボックスといった定石の位置づけが見えてきます。
ここで注意したいのは、CQRSやイベントソーシングは万能薬ではなく、複雑性と引き換えのトレードオフだという点です。リストの各記事もメリットだけでなく適用条件に触れているものが多く、「まず単純なCRUDで足りないか」を問うてから採用するのが定石です。強整合が必要な場面まで無理に結果整合へ倒すと、かえってバグの温床になります。どの一貫性モデルを選ぶかは、業務要件（どこまでの遅延・不整合を許容できるか）から逆算するのが原則で、その判断材料としてリストの記事群は役立ちます。
マイクロサービスを学ぶ——通信・可観測性・回復性・APIゲートウェイ
マイクロサービスは、このリストで最も細かく分解されている分野です。「マイクロサービスとは」だけでなく、運用で必ずぶつかる論点が独立ページとして整理されています。
READMEに沿って主要な論点を挙げると次の通りです。
・通信（Communication）：同期・非同期、REST vs メッセージベース、サービスバスの使い分け
・サービス境界（Service Boundaries）：DDDの境界づけられたコンテキストを使った分割の考え方
・可観測性（Observability）：分散トレーシング、モニタリング、ロギング、相関ID（CorrelationId）、そしてEFK／ELK／Fluent Bit／Fluentd／Lokiといったログ基盤の具体ツール
・回復性（Resiliency）：冪等性（Idempotency）、高可用性（High Availability）
・APIゲートウェイ（API Gateway）：Ambassador／Kong／Ocelotなど実装別のページ
・セキュリティ：キーボールト（Key Vault）によるシークレット管理
・ツール（Tools）：CAP／Dapr／MassTransit／NServiceBus／Steeltoe／Tye／Wolverineなど
このように、マイクロサービスを「概念」だけでなく「通信・可観測性・回復性」といった運用の現実まで分けて学べるのがこの分野の価値です。特に可観測性のツール群（EFK／ELK／Loki）まで踏み込んでいる点は、実際にマイクロサービスを運用する段階で効いてきます。なお、ツール節はDapr以外にAkka.NET・Orleans・Ocelot・CAP・MassTransit・Wolverineなど.NETエコシステムのプロジェクトが目立ちます。作者の背景を反映したものと考えられますが、扱う設計論点自体は言語を問いません。
設計原則を学ぶ——SOLID・DRY・KISS・YAGNIと20の指針
「Architectural Design Principles（アーキテクチャ設計原則）」分野は、コードレビューや設計判断の“共通言語”を揃えるのに最適です。単発の格言ではなく、約20の原則が独立ページで解説されています。
| グループ | 収録される主な原則 | 効く場面 |
|---|---|---|
| オブジェクト指向の骨格 | SOLID（SRP / OCP / LSP / ISP / DIP）、GRASP | クラス・モジュールの責務配分 |
| 結合と凝集 | 凝集度（Cohesion）、結合度（Coupling）、依存性逆転、IoC | 変更に強い依存関係を作る |
| シンプルさ | DRY、KISS、YAGNI、継承より合成 | 過剰設計・重複を避ける |
| 分離の原則 | 関心の分離、コマンドクエリ分離（CQS）、横断的関心事、永続性非依存 | ドメインを技術詳細から守る |
| 移行・堅牢性 | Strangler Figパターン、Fail Fast、カプセル化 | レガシー刷新・早期の失敗検知 |
原則は「知っている」と「使える」のあいだに大きな差があります。SOLIDを暗記していても、目の前のクラスがSRP違反かを判断できるとは限りません。このリストの各原則ページには「原則が破られた具体例」と「リファクタリング後」を示す記事が集まっており、抽象的な格言を実際のコードに接続する助けになります。
・レビュー観点を揃えたいチームは、まずSOLIDと結合・凝集の2ページを共有言語にすると議論がかみ合う
・「とりあえず作る」に効くのがKISS・YAGNI、「重複を消す」に効くのがDRY——ただしDRYの効かせすぎは結合を招くため注意
・レガシー刷新を控えているならStrangler Figパターンの記事を先に読んでおくと計画が立てやすい
このほか、Design Patterns（GoF由来のパターン群）、Cloud Design Patterns（クラウド固有のパターン）、Systems Design（システム設計）、Scaling（スケーリング）、Caching（キャッシュ）といった分野も同様の粒度で整理されています。役割を整理すると、設計原則で“語彙”を、デザインパターンで“定石”を、システム設計で“全体設計”を、スケーリングとキャッシュで“性能”を、と段階的に守備範囲を広げていけます。
たとえばDesign Patternsは、アダプター・ビルダー・責任の連鎖（Chain of Responsibility）・コマンドメッセージパターンなど、GoFの古典から実務でよく使うものまでを個別ページに分けています（一部は説明が「TODO」でも記事リンクは収録済み）。Cloud Design Patternsは、リトライ・サーキットブレーカー・アウトボックスといった、クラウド／分散環境で頻出のパターンを扱います。そしてSystems Designは、いわゆる「システム設計面接」で問われる大規模設計の考え方に対応し、Scaling（水平／垂直スケール）やCaching（キャッシュ戦略）、Sharding（シャーディング）と組み合わせて読むと、負荷にどう耐えるかの設計判断が体系化されます。「原則→パターン→全体設計→性能」の順に読み進めるのが、独学のひとつの王道ルートです。
AI・RAG時代にアーキテクチャ知識が効く理由
このリストは特定のAI製品を解説するものではありません。ただし、無関係でもありません。リスト自体にAI分野が設けられ、AIとRAG（Retrieval-Augmented Generation／検索拡張生成）のページが用意されています。AIアプリケーションもまた、境界の切り方・データの流れ・非同期処理・可観測性といった“ふつうの設計問題”から逃れられない、という認識の表れです。
実務の肌感でも、AIコーディングエージェントが設計そのものを肩代わりしてくれるわけではありません。エージェントに「集約を切って」「CQRSで読み書きを分けて」と的確に指示するには、人間側にDDDやCQRSの語彙が要ります。生成されたコードが貧血ドメインモデルに陥っていないか、境界づけられたコンテキストを跨いでいないかを見抜くのも、結局は設計知識です。つまり、このリストが束ねる知識はAI時代にこそ効く土台になります。
なお、AI時代の「自動化ツールをどう選ぶか」という観点は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 で整理しています。ツールの選定軸と、本記事の設計知識の地図は補完関係にあります。
このリストの歩き方——用途から引く学習ルート
awesome-software-architectureは、上から順に全部読むための本ではありません。「用途から引く」のが最も効率的な使い方です。
具体的には次の流れです。まず①いま解きたい設計課題を言語化します（例：「注文機能のドメインをきれいに設計したい」）。次に②該当分野を引きます（この例ならDDDの「集約」「境界づけられたコンテキスト」）。そして③⭐付きのおすすめ記事から読み、最後に④小さく手を動かして試す。この往復を繰り返すと、リストが「読むもの」から「引くもの」へ変わり、設計の意思決定のたびに立ち返る個人用リファレンスになります。
逆に非効率なのは「トップから全ページを踏破しようとする」使い方です。253ページを順に読むのは現実的でなく、途中で力尽きます。地図は目的地が決まってこそ役に立ちます。まずは自分のいまのタスクに一番近い1分野を開くところから始めてください。
チーム学習に使う場合は、分野ごとに担当を割り振り、⭐記事を1〜2本ずつ読んで社内で共有する、という運用も有効です。CC0ライセンスなので、社内Wikiへリンク一覧を転記して独自の学習パスを組んでも問題ありません（リンク先記事の二次利用は各条件に従います）。
他の学習リソースとどう違うか
設計を学ぶ手段は、書籍・公式ドキュメント・動画講座などいくつもあります。awesome-software-architectureの立ち位置を、他の選択肢と比べて整理します。
| リソース | 強み | 弱み | 向いている人 |
|---|---|---|---|
| awesome-software-architecture | 分野別の厳選リンク集・⭐で当たりが分かる・無料・CC0 | 説明が未整備の項目あり・.NET寄り・体系書ではない | 「まず何を読むか」を素早く決めたい独学者 |
| 設計の名著（書籍） | 体系的で深い・一貫した論理 | 時間とコスト・更新が遅い | 1テーマをじっくり腰を据えて学びたい人 |
| 公式ドキュメント | 一次情報で正確・最新 | 特定製品/言語に限定・横断が難しい | 採用技術が固まっている人 |
| awesome-sysadmin 等の姉妹リスト | 運用ツールの地図 | 設計“知識”は扱わない | ツール選定が目的の運用者 |
要するに、awesome-software-architectureは「体系書の代わり」ではなく「体系書へたどり着くための索引」です。深く学ぶ入口を素早く見つけ、そこから書籍や公式ドキュメントへ潜っていく——その最初の一歩を短縮するのが、このリストの役割です。無料で、しかもCC0で自由に使えることを踏まえると、独学者が最初に手元へ置いておくべきブックマークだと言えます。
ライセンス・メンテナンス・コントリビュート（CC0-1.0）
ライセンスはCC0-1.0（Creative Commons Zero）です。これは著作権を可能な限り放棄するパブリックドメイン相当の宣言で、リスト（キュレーション）自体は出典表示すら必須とせず、引用・改変・再配布・商用利用が広く認められます。社内資料やブログに転記して独自の学習マップを組むことも問題ありません。ただし繰り返しになりますが、リンク先の各記事・動画にはそれぞれの著作権があります。二次利用の際はリンク先の条件を個別に確認してください。
メンテナンス状況は活発で、直近までコミットがあります。一方で、READMEの一行説明には「TODO…」の項目が多く残っており、リスト全体が“完成”しているわけではありません。これは欠点というより、コミュニティで育て続ける前提の生きた索引だと理解するのが適切です。新しい良質な記事を見つけたら、contributing.md に沿ってプルリクエストで該当分野へ追加できます。自分の学習の副産物をリストへ還元する、という参加の仕方も、このリストの成り立ちに沿っています。
まとめ——設計を独学する人の「最初の地図」
awesome-software-architectureは、ソフトウェアアーキテクチャ・設計パターン・設計原則の学習リソースを54分野・253ページに束ねた、設計独学者のための地図です。Clean Architectureから始まる各種アーキテクチャ様式、19概念に分解されたDDD、読み書きを分けるCQRS、運用の現実まで踏み込むマイクロサービス、約20の設計原則——これらを「まず何を読むべきか」の当たり付きで俯瞰できます。
説明が未整備の項目や.NET寄りといった弱みはあるものの、CC0で自由に使え、⭐印で良質な入口が示される価値は大きく、独学者・チームのオンボーディングの双方で役立ちます。AIそのものの解説ではありませんが、AIエージェントに設計を的確に指示し、その出力を評価するための土台知識としても、この地図は効いてきます。まずは自分のいまのタスクに一番近い1分野を開くところから、使い始めてみてください。
参照ソース
・mehdihadeli/awesome-software-architecture（GitHub公式リポジトリ） — 54分野のカテゴリ一覧・各コンセプトページ・ライセンス（CC0-1.0）・コントリビューションガイドの一次ソース
・Awesome Software Architecture（公式サイト awesome-architecture.com） — READMEと同内容を検索しやすい形で公開した公式ドキュメントサイト（mkdocs）
