Domain
ソフトウェア設計
クリーンコードからアーキテクチャ、テスト・品質文化まで、ソフトウェア設計の体系的学習パス。 コード品質、テスト駆動開発、ドメイン駆動設計、分散システム設計、DevOps/品質組織までカバー。
この分野の地形
ソフトウェア設計の地形は、足元の「読みやすいコード」から始まり、 品質を保つ習慣（リファクタリング・テスト駆動開発）を経て、 システム全体を見渡す「アーキテクチャ」の高地へと続く一本の登り道として描ける。
最初の大陸は、変数名・関数・責務といったミクロな単位を扱う「コード品質」の領域。 ここを越えると、コードを壊さず育てるための「テスト・リファクタリング」の丘陵が広がり、 その先に、依存の向きと境界を設計する「クリーンアーキテクチャ」「ドメイン駆動設計」の山脈が現れる。
さらに奥地には、分散システム・データ指向設計・DevOps/品質組織といった 「大規模・運用」の高原が広がる。この分野を俯瞰する鍵は、 ミクロ（コード）からマクロ（組織・運用）まで、関心事のスケールが連続して繋がっている点にある。
矢印の向きに読み進めます／実線＝必須・破線＝推奨
この地図を共有
グループ化
難易度
難易度
依存関係
グラフを計算中...
収録書籍
33件
Head Firstデザインパターン
頭とからだで覚えるデザインパターンの基本
Eric Freeman, Elisabeth Robson
リーダブルコード
より良いコードを書くためのシンプルで実践的なテクニック
Dustin Boswell, Trevor Foucher
LeanとDevOpsの科学[Accelerate]
テクノロジーの戦略的活用が組織変革を加速する
Nicole Forsgren, Jez Humble, Gene Kim
マイクロサービスアーキテクチャ
第2版
Sam Newman
Clean Architecture
達人に学ぶソフトウェアの構造と設計
Robert C. Martin
Clean Code
アジャイルソフトウェア達人の技
Robert C. Martin
Designing Distributed Systems
Patterns and Paradigms for Scalable, Reliable Services
Brendan Burns
Effective Software Testing
A developer's guide
Maurício Aniche
ソフトウェアアーキテクチャの基礎（第2版）
エンジニアリングに基づく体系的アプローチ
Mark Richards, Neal Ford
生成AI時代のソフトウェア開発
ツールを賢く選択、評価、活用し、より速く効率的な開発を進めるために
Sergio Pereira
ドメイン駆動設計をはじめよう
ソフトウェアの実装と事業戦略を結びつける実践技法
Vlad Khononov
達人プログラマー
熟達に向けたあなたの旅 第2版
David Thomas, Andrew Hunt
リファクタリング
既存のコードを安全に改善する 第2版
Martin Fowler
責任あるソフトウェアエンジニアリング
現実社会におけるGoogleのケーススタディとともに
Daniel Barrett, Google Engineering
テスト駆動開発
Kent Beck
チームトポロジー
価値あるソフトウェアをすばやく届ける適応型組織設計
Matthew Skelton, Manuel Pais
単体テストの考え方/使い方
Vladimir Khorikov
レガシーコード改善ガイド
Michael C. Feathers
進化的アーキテクチャ
絶え間ない変化を支える
Neal Ford, Rebecca Parsons, Patrick Kua
Building Secure and Reliable Systems
Best Practices for Designing, Implementing, and Maintaining Systems
Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield
データ指向プログラミング
ソフトウェアがもつ複雑さの軽減に向けて
Yehonathan Sharvit
データ指向アプリケーションデザイン
信頼性、拡張性、保守性の高い分散システム設計の原理
Martin Kleppmann
エリック・エヴァンスのドメイン駆動設計
Eric Evans
フルスタックテスティング
10のテスト手法で実践する高品質ソフトウェア開発
Gayathri Mohan
オブジェクト指向における再利用のためのデザインパターン
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
実践テスト駆動開発
テストに導かれてオブジェクト指向ソフトウェアを育てる
Steve Freeman, Nat Pryce
LEADING QUALITY
優れたリーダーはいかにして高品質のソフトウェアを提供し成長を加速させるか
Ronald Cummings-John, Owais Peer
モノリスからマイクロサービスへ
モノリスを進化させる実践移行ガイド
Sam Newman
エンタープライズ アプリケーションアーキテクチャパターン
Patterns of Enterprise Application Architecture
Martin Fowler
A Philosophy of Software Design, 2nd Edition
John Ousterhout
実践プロパティベーステスト
PropErとErlang/Elixirではじめよう
Fred Hebert
ソフトウェアアーキテクチャ・ハードパーツ
分散アーキテクチャのためのトレードオフ分析
Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani
Googleのソフトウェアエンジニアリング
持続可能なプログラミングを支える技術、文化、プロセス
Titus Winters, Tom Manshreck, Hyrum Wright
依存関係
理由: 『The DevOps ハンドブック』で DevOps の文化と実践を学んだら、それを超巨大組織が長期間どう運用しているかの実例へ。『Googleのソフトウェアエンジニアリング』は「時間の経過とともに変化するプログラミング」という視点で、大規模・長寿命なエンジニアリング文化の知見を与えるクロスドメインな橋渡し。
理由: JavaScript のテスト戦略を確立したら、フロントエンドに閉じず CI/CD まで含めた品質の全体最適へ視野を広げる。フルスタックテスティングは契約・性能・セキュリティ・E2E を横断する品質戦略を与え、テストを開発文化として位置づける。
理由: フロントエンドを独立した部品へ分割する発想を掴むと、それがバックエンドのマイクロサービスと同じ根を持つことに気づく。マイクロサービスアーキテクチャは境界・自律デプロイ・組織との対応というサーバー側の体系を与え、分散の原理を両面から理解させる。
理由: 良いコードの基準を学んだ次は、既存コードをその基準へ安全に近づける技術が要る。リファクタリングは「コードの臭い」を手がかりに振る舞いを変えず構造を改善する体系を与える。
理由: クリーンなコードを書き続けるには、変更を恐れず検証できる足場が要る。テスト駆動開発は「動くきれいなコード」を小さなサイクルで育てる規律を与え、品質を習慣として定着させる。
理由: 関数やクラス単位の品質が身についたら、次はシステム全体の依存の向きと境界を設計する視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える原則を与える。
理由: 図解と豊富な例でパターンを体感的に掴んだら、意図・適用可能性・帰結が厳密に定義された原典で語彙を確かにする。GoF はパターンを設計の共通言語として体系化し、議論の土台を与える。
理由: TDD の小さなサイクルで「動くテスト」を書く感覚を得たら、何を・どの粒度でテストするかの設計原則へ進む。良いテストは壊れにくく、リファクタリングを妨げず、回帰を確実に捉える。
理由: 単体の TDD に慣れたら、外側から駆動する TDD（受け入れテスト→単体）でオブジェクト間の協調そのものを設計する段階へ進む。モックは実装の代用ではなく、協調を表現する設計ツールになる。
理由: 安全なリファクタリング手順を身につけたら、テストの無いレガシーコードという最難関へ挑む。まず依存を切り離す継ぎ目を見つけてテストで覆い、変更の安全網を張ってから構造を直す。
理由: クリーンアーキテクチャで「あるべき形」の直観を得たら、アーキテクチャ特性やトレードオフを体系的な語彙で扱えるようにする。本書は属人的な設計判断を、議論可能な工学へと引き上げる。
理由: 依存の向きを制御できるようになると、次の関心は「境界をどこに引くか」へ移る。ドメイン駆動設計はビジネスの言葉から境界づけられたコンテキストを導き、アーキテクチャの分割に意味を与える。
理由: アーキテクチャ特性とトレードオフの語彙を得たら、その判断を分散システムという具体に適用する。マイクロサービスは独立デプロイと自律性のために、あえて結合を切る設計を要求する。
理由: 基礎的な特性を理解したら、唯一の正解が無い「難所」——分解の粒度・データ所有・分散トランザクション——でのトレードオフ分析へ進む。同じ著者陣が「答え」ではなく「判断の仕方」を示す。
理由: 静的なアーキテクチャ判断を学んだら、変化に適応し続ける設計へ視野を広げる。適応度関数でアーキテクチャ特性を継続的に検証し、進化を計測可能なものにする考え方を得る。
理由: 入門書で戦略・戦術の地図を得たら、概念の出どころと厳密な定義を原典で確かめる。エヴァンスの DDD はユビキタス言語やモデル駆動設計の根拠を与え、応用の判断を支える土台になる。
理由: マイクロサービスの原則を理解したら、既存モノリスからの現実的な移行戦略へ進む。多くの成功例はモノリスから段階的に切り出しており、最初から分散させない判断も含めて学ぶ。
理由: サービスを分割すると、次の難所はデータの分散・整合性・信頼性になる。DDIA は複製・分割・トランザクションといった分散データシステムの基礎理論とトレードオフを体系的に与える。
理由: 良いテストの原則を理解したら、テストを書きにくいレガシーコードへその原則を適用する。依存を断ち切る継ぎ目を作り、特性テストで現状の振る舞いを固定してから安全に変更する。
理由: テスト単体の良し悪しを判断できるようになったら、テストでオブジェクトの責務と協調を「育てる」設計手法へ広げる。テストダブルの使い分けが設計のフィードバックになる。
理由: 依存と境界の原則を得たら、その根底にある「複雑性をどう抑えるか」という普遍的な問いへ降りる。Ousterhout は深いモジュール・情報隠蔽という観点で複雑性管理を体系化する。
理由: 戦術的な改善手段を持ったら、「なぜ改善するのか」の戦略的視点＝複雑性の正体へ視野を上げる。リファクタリングの判断基準に「複雑性を減らせているか」という軸が加わる。
理由: 良いテストの性質（回帰の検出・壊れにくさ・素早いフィードバック）を理解したら、境界値分析・同値分割・構造化テストといった体系的な技法で「何をテストすべきか」を引き上げる。直感頼みのケース選びを工学にする。
理由: 例示ベースのテスト技法を押さえたら、入力を網羅的に生成して不変条件を検証するプロパティベーステストへ進む。人が思いつかない反例を機械に探させ、仕様の穴をあぶり出す。
理由: 単体テストの土台ができたら、テストピラミッドに沿って統合・契約・E2E テストを適切な比率で積み上げ、システム全体の品質戦略へ広げる。下層を厚く、上層を薄くが原則。
理由: テストと CI/CD で品質を作り込む土台ができたら、それが組織のデリバリ性能にどう効くかを計測の視点で捉える。DORA の4指標は「速さと安定はトレードオフではない」ことを実証的に示す。
理由: デリバリ性能を計測で改善できるようになったら、それを大規模・長期で支える組織文化と工学的実践へ視野を広げる。Google は「時間とスケールを統合したプログラミング」として持続可能性を論じる。
理由: 大規模組織の工学的実践を理解したら、品質を「個人の努力」から「組織が育てる文化」へと引き上げるリーダーシップの視点へ進む。品質はマネジメントの戦略課題になる。
理由: 技術的な品質戦略を一通り押さえたら、それをチーム・組織のレベルで根づかせる方法へ視野を広げる。テストの量や種類ではなく、品質に対する意思決定と文化が主題になる。
理由: 技術的な境界を設計できるようになったら、その境界がチーム構造と相互に影響し合う事実（コンウェイの法則）へ視野を広げる。アーキテクチャはコードだけでなく組織の問題でもある。
理由: チーム境界を流れに沿って設計したら、その境界をビジネスドメインの言葉で裏打ちする。境界づけられたコンテキストは、チームの輪郭とモデルの輪郭を同時に定義する。
理由: サービスを切り出す移行を進めると、分割の単位がチームの認知負荷と一致しているかが問われる。逆コンウェイ戦略で、望むアーキテクチャに合わせてチームを編成し直す。
理由: 適応度関数で進化を導く発想を得たら、同じ著者陣が扱う分散アーキテクチャの難所——粒度・データ所有・通信のトレードオフ——の具体的な分析へ進む。
理由: テスト駆動で設計を育てる実践を経たら、テストケースそのものの十分性を体系的な技法で高める。設計の良さとケースの網羅性という両輪を回し、テストの抜けを減らす。
理由: 複雑性を抑える普遍原則を得たら、それをドメインの複雑性に特化して適用する。DDD はビジネスに内在する本質的な複雑性を、モデルとユビキタス言語で飼いならす。
理由: コード単位の品質基準を身につけたら、その表現力をドメインの言葉へ向ける。意味のある名前は、ユビキタス言語としてビジネスとコードを橋渡しし、モデルを語れるコードにする。
理由: 依存方向と境界の原則は、サービス境界の設計にそのまま効く。境界づけられた責務を、独立にデプロイ可能な単位へ写像する具体的な設計判断へつなげる。
理由: テスト設計の原則はフロントエンドにも通じる。テストピラミッドを土台に、UI は少数の E2E で要を押さえ、ロジックは単体で厚く守る——層を跨いでも判断基準は同じ。
理由: 命名や関数分割といった可読性の基礎を押さえたら、それらを「なぜそうするのか」の原則へ束ねる段階に進む。クリーンコードは個別テクニックを職業倫理と設計原則の体系へと接続する。
理由: 命名や整形といった可読性の具体技法を押さえたら、日々の判断を貫く職業哲学（DRY・直交性・変化への構え）へ視野を広げる。達人プログラマーは個々のテクニックを「なぜそうするか」の態度へ束ねる。
理由: 読みやすいコードの形を知ったら、既存コードを壊さずその形へ寄せていく技法が要る。リファクタリングは「コードの臭い」を手がかりに、振る舞いを変えず小さく構造を改善する段取りを与える。
理由: 達人の心構え（割れた窓を放置しない・DRY を徹底する）を得たら、それを関数やクラス単位の具体的な品質基準へ落とし込む。クリーンコードは「良いコードとは何か」を原則と実例で体系化する。
理由: 「割れた窓を放置しない」という達人の規律を、実際のコードへ適用する手段がリファクタリングである。劣化の兆候を見つけたその場で、振る舞いを保ったまま小さく直す習慣に変える。
理由: 層と依存方向の原則を得たら、それを実装へ落とす定番パターン（Repository・Service Layer・Domain Model）の原典へ進む。原則とパターンが対応づくと設計の語彙が一段深まる。
理由: 単一DBを前提としたエンタープライズパターンを押さえたら、複数ノードに分散したデータの一貫性・レプリケーション・パーティショニングへ視野を広げる。スケールの前提が変わる。
理由: 汎用的なオブジェクト間パターンを学んだら、層・永続化・分散といったエンタープライズ固有の文脈に効くパターン群へ進む。Fowler の PoEAA はその語彙（Repository・Domain Model 等）を与える。
理由: パターンを認識できる目を持つと、既存コードを「あるべきパターン」へ向けて安全に動かす技法が活きる。リファクタリングはパターン導入を一足飛びにせず、段階的な変換として進める道筋を与える。
理由: 不変条件の検証技法を持ったら、それを単体から統合・E2E までの品質戦略の中に位置づける。各層で「何を性質として保証するか」を設計し、ピラミッド全体に一貫性を与える。
理由: ドメインモデルをオブジェクトで表現する手法を学んだら、対照的に「コードとデータを分離し、不変データで複雑性を抑える」データ指向の発想に触れ、設計の前提を相対化する。
理由: 複雑性管理の一般原則を得たら、その具体的な処方の一つとして「データと振る舞いの分離・不変性」を掲げるデータ指向プログラミングを検討する。同じ目的に異なる道がある。
理由: パターンの目で既存コードの構造を読めるようになると、テストの無いレガシーコードに安全に手を入れる足場づくりへ進める。継ぎ目を見つけてテストで覆い、そこから設計を改善していく。
理由: クラス／オブジェクト単位のパターン語彙を得たら、それらを束ねてシステム全体の依存方向と境界を律する視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える。
理由: 境界づけられたコンテキストを引けるようになったら、その境界をチーム編成へ写像する。コンテキストとチームを一致させると認知負荷が下がり、価値の流れが速くなる。
理由: 分散アーキの難所でデータ分解の判断を迫られたら、その土台となる分散データの理論へ降りる。整合性・レプリケーション・ストレージエンジンの原理が、設計判断の根拠になる。
理由: 大規模組織の工学的実践を理解したら、生成 AI が開発の流れをどう変えるかを同じ規律で捉える。AI は道具であり、レビュー・テスト・設計判断という土台があってこそ生きる。
理由: 達人の心構え（道具を磨き、自分の判断に責任を持つ）を得たら、生成 AI を新しい道具として取り込む。AI の出力を鵜呑みにせず検証できる基礎力こそ、AI 時代の達人性になる。
理由: AI を開発に取り込めるようになったら、その力が社会に及ぼす影響＝責任の問いへ進む。生成物の正しさ・バイアス・説明責任を、設計の段階から織り込む視点を持つ。
理由: システムの安全性と信頼性を設計に組み込めるようになったら、その射程を利用者・社会への責任まで広げる。技術的な堅牢さは、倫理的・社会的な責任を果たすための土台になる。
次に探索する
依存関係でつながる分野