目的地
「エリック・エヴァンスのドメイン駆動設計」に至る道筋
この本にたどり着くために、先に読んでおきたい本を依存関係から逆算しました。基礎から順に並んでいます。
ここまでの道筋（8冊）
なぜ先に読むのか: 命名や関数分割といった可読性の基礎を押さえたら、それらを「なぜそうするのか」の原則へ束ねる段階に進む。クリーンコードは個別テクニックを職業倫理と設計原則の体系へと接続する。
なぜ先に読むのか: 達人の心構え（割れた窓を放置しない・DRY を徹底する）を得たら、それを関数やクラス単位の具体的な品質基準へ落とし込む。クリーンコードは「良いコードとは何か」を原則と実例で体系化する。
なぜ先に読むのか: 関数やクラス単位の品質が身についたら、次はシステム全体の依存の向きと境界を設計する視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える原則を与える。
なぜ先に読むのか: システム内部の境界を設計できるようになったら、その境界をプロセス＝サービスへ分割すべきかという次の判断へ進む。Monolith to Microservices は「まずモノリスから」という現実的な指針のもと、分割の動機・進め方・落とし穴を体系立てる。
なぜ先に読むのか: マイクロサービスの原則を理解したら、既存モノリスからの現実的な移行戦略へ進む。多くの成功例はモノリスから段階的に切り出しており、最初から分散させない判断も含めて学ぶ。
なぜ先に読むのか: 入門書で戦略・戦術の地図を得たら、概念の出どころと厳密な定義を原典で確かめる。エヴァンスの DDD はユビキタス言語やモデル駆動設計の根拠を与え、応用の判断を支える土台になる。
なぜ先に読むのか: サービスを切り出す移行を進めると、分割の単位がチームの認知負荷と一致しているかが問われる。逆コンウェイ戦略で、望むアーキテクチャに合わせてチームを編成し直す。
なぜ先に読むのか: チーム境界を流れに沿って設計したら、その境界をビジネスドメインの言葉で裏打ちする。境界づけられたコンテキストは、チームの輪郭とモデルの輪郭を同時に定義する。