mattpocock skillsを再評価｜19万★『Skills For Real Engineers』設計思想を読む

mattpocock skillsは、TypeScript教育界隈で著名なMatt Pocock氏が公開する 「Skills For Real Engineers」 というクレドを掲げたClaude Code向けスキル集だ。2026年2月の公開後にGitHubスター193,295・Fork 16,631（2026-07-29時点）まで伸び、Claude Code Skillsエコシステムの中で実質的な参照実装になりつつある。本リポジトリの興味深さは、スキルの個別機能というより、「AIエージェントが失敗する4つの理由」を構造的に潰すという設計思想にある。

この記事ではmattpocock/skillsを、READMEで明示される4つの失敗モードとそれに対応するスキル群の対照関係から読み解く。エージェント基盤の選び方そのものは AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 を起点にすると整理しやすい。現在の41スキルの構成・導入ルート・呼び出し方は mattpocock/skills完全ガイド｜Claude Code用スキル集で開発プロセスを自動化 で扱っている。

なぜmattpocock skillsは19万★まで伸びたのか

mattpocock/skillsのREADMEは、リポジトリの自己紹介を次のように要約している。

My agent skills that I use every day to do real engineering - not vibe coding.

「Vibe Codingじゃなくて、本物のエンジニアリングをやるためのスキル」という宣言は、過去半年で乱立した「AIにすべて任せるBMAD・GSD・Spec-Kit系」のフレームワークへのアンチテーゼでもある。READMEはこの点を明示している。

Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve.

つまり、mattpocock skillsの設計思想は 「プロセスを奪わない」 と 「小さく・適応可能に・組み合わせ可能に」 に集約される。これは、TypeScript型システムの教育で培われた「abstraction is a tool, not a goal」の延長線上にある考え方だ。

リポジトリの素性

npx skills@latest add という配布方式は、Composio系の awesome-codex-skills や Cloudflare系の cloudflare/skills とは別系統のCLI（skills-cli）を採用している点が独特だ。インストール時に「どのスキルを入れるか」「どのコーディングエージェントに紐付けるか」を対話的に選べる。

30秒セットアップの実体

READMEの「Quickstart」を分解すると、次の3ステップに集約される。

# 1. インストーラ起動（対話形式）
npx skills@latest add mattpocock/skills

# 2. 必ず /setup-matt-pocock-skills を選択

# 3. エージェント側で初期化スキルを実行
/setup-matt-pocock-skills

/setup-matt-pocock-skills を実行すると、リポジトリ内のスキル群が前提とする「設定」を対話的に決められる。具体的には次の3点だ。

• 課題管理ツール（GitHub・Linear・ローカルファイルから選択）
• トリアージ用のラベル語彙（/triage で参照）
• ドキュメント生成先のディレクトリ（docs/adr/ など）

この初期化スキルが「他スキルの前提を一カ所に集約する」ハブとして機能している点が、mattpocock skillsの実装的な特徴だ。

4大AI失敗モードと、それを潰す旗艦スキル

mattpocock skillsの真価は、READMEの後半に書かれている 「4 AI Failure Modes」 とスキルの対応関係にある。READMEはそれぞれの失敗モードを引用付きで定義している。

失敗モード1：Misalignment——/grill-meと/grill-with-docs

最頻出の失敗は「指示と成果物のズレ」だ。READMEは『The Pragmatic Programmer』の引用を添えている。

“No-one knows exactly what they want” — David Thomas & Andrew Hunt

人間同士のコミュニケーションが本質的に曖昧であるように、AIエージェントとの会話も同じ問題を抱える。Mattの解は 「実装前に grill（焼く）する」 というシンプルなものだ。

• /grill-me：非コード用途のグリル（仕様議論・要件定義）
• /grill-with-docs：コード用途のグリル＋CONTEXT.md／ADR の更新

特に /grill-with-docs はリポジトリ内で「最も人気のスキル」と位置付けられている。ただ要件を聞き出すだけでなく、ドメインモデルの矛盾を炙り出し、CONTEXT.md と docs/adr/ に決定事項を残す動きまで内蔵している。

失敗モード2：Verbosity——CONTEXT.mdと/grill-with-docs

2番目の失敗は「AIが冗長になる」「同じ概念を異なる言葉で呼ぶ」というもの。これはエリック・エヴァンスのユビキタス言語の不在に対応する。READMEは具体例として、コース動画管理アプリのCONTEXT.md を引用している。

BEFORE: “There’s a problem when a lesson inside a section of a course is made ‘real’ (i.e. given a spot in the file system)” AFTER: “There’s a problem with the materialization cascade”

短くなっただけではない。「materialization cascade」 という共有語が定義されたことで、以降の会話・コード・ドキュメントが一貫した語彙を獲得する。

この共有語の獲得は、現在のREADMEでは /grill-with-docs の内側に畳み込まれている。詰問セッションを回しながら、その場で CONTEXT.md とADRを更新していく形だ。READMEはこの手法を「このリポジトリで最もクールな技法かもしれない」と書き、効果として「変数・関数・ファイル名が一貫する」「コードベースをエージェントがナビゲートしやすくなる」「共有語がある分、思考に消費されるトークンが減る」の3点を挙げている。

失敗モード3：Doesn’t Work——/tddと/diagnosing-bugs

3番目の失敗は「合意は取れたのに、できたコードが動かない」。これはフィードバックループの不足が原因で、Mattの処方箋は古典的な TDDとデバッグループ の徹底だ。

# /tdd フローを起動
/tdd

# エージェントは red-green-refactor を強制
# 1. RED: 失敗テストを先に書く
# 2. GREEN: 最小実装でテストを通す
# 3. REFACTOR: テストを保ったまま整理

/tdd はバーティカルスライス単位で進める設計が特徴で、機能を縦に薄くスライスして1ループで完結させる。/diagnosing-bugs は別のループで、再現→最小化→仮説→計装→修正→回帰テスト という6段階のデバッグ手順を強制する。「再現」と「最小化」が独立ステップで強制されるのが秀逸で、AI が見切り発車で修正案を出すのを構造的に防ぐ。

TDDサイクルが効果を発揮する条件

/tdd で red-green-refactor を強制しても、テストの粒度が粗いと品質ループは機能しない。Mattのスキルは「vertical slice」を単位として小さく刻むことを強く要求する。たとえば「ユーザー登録フォームの追加」というタスクなら、「メール形式バリデーション → 重複チェック → DB登録 → 確認メール送信」のように、ユーザー価値が独立して成立する単位まで分解する。

このスライス感は、AIエージェントが暴走する典型パターン――「機能を一気に書き上げてしまう／テストはあとで／結局動かないので全部捨てて書き直す」――を構造的に防ぐ。/diagnosing-bugs がデバッグループを決定論的にするのも同じ思想で、AI が憶測で修正案を出す前に、再現条件と最小ケースを必ず固定させる動作を強制している。

失敗モード4：Ball of Mud——/to-spec・/improve-codebase-architecture

4番目の失敗は「AIで開発を加速したらコードベースが泥団子になった」という最も深刻なもの。READMEはケント・ベックとオースタハウトの2引用を並べている。

“Invest in the design of the system every day.” — Kent Beck “The best modules are deep.” — John Ousterhout

mattpocock skillsはこの問題を分業で潰そうとする。

• /to-spec：着手前に「どのモジュールを触るか」をクイズしてから仕様を作る
• /improve-codebase-architecture：泥団子化した箇所を走査し、HTMLレポートで候補を提示してから詰める

特に /improve-codebase-architecture は、CONTEXT.md のドメイン語彙と docs/adr/ の決定事項を踏まえて改善案を出すため、無秩序なリファクタを抑制できる。Mattは「数日に1回これを回せ」と推奨している。

なお「上級エンジニアの思考をスキルとして注入する」という発想自体は、mattpocock skills だけのものではない。同じ方向を別の切り口で追った例として Addy OsmaniのAgent Skills｜AIコーディングエージェントに上級エンジニアの思考を注入する20のスキル があり、読み比べると「どこを型にするか」の判断差が見えて面白い。

設計思想は残り、それを担うスキルは入れ替わった

この記事の初出（2026年5月）から、リポジトリの中身はかなり動いている。 2026年7月29日時点で skills/ 配下の SKILL.md を数えると41個あり、公開当初に紹介された18スキルの構成とは別物になっている。

興味深いのは、4大失敗モードという枠組みそのものは今もREADMEの骨格として生きている点だ。 変わったのは、それぞれの失敗を担当する「担い手」のほうだった。

さらに、初期に紹介された ubiquitous-language・request-refactor-plan・qa・design-an-interface の4つは skills/deprecated/ へ移された。 write-a-prd 系（prd-to-plan／prd-to-issues）と caveman は現在のツリーから消えている。

ここから読み取れる設計上の含意は2つある。

第一に、枠組みが実装より長生きしていること。 スキルは足され・改称され・非推奨化されたが、「AIエージェントが失敗する4つの理由」という分類は2026年2月の公開時から一貫している。 スキル集を評価するとき、個々のコマンド名ではなく「どの失敗モードに賭けているか」を見るべき理由がここにある。

第二に、統合の方向に動いていること。 /caveman が単独スキルとして消え、ユビキタス言語の獲得が /grill-with-docs の内側に畳み込まれたのは典型例だ。 READMEは CONTEXT.md を軸にした共有語の構築を「このリポジトリで最もクールな技法かもしれない」と書き、それを詰問セッションの一部として提供する形に寄せている。 スキルを増やすより、既に使われている入口に機能を寄せる——という判断が読み取れる。

現在どのスキルが入っていて、どう導入し、どう呼び出すかというカタログ面は mattpocock/skills完全ガイド｜Claude Code用スキル集で開発プロセスを自動化 が扱う。 本記事はそちらと役割を分け、「なぜそう作られているか」 に絞って読み解く。

awesome-codex-skills・他スキル集との相互運用とCodex対応

mattpocock skillsの設計はClaude Code Skills準拠（フォルダ＋SKILL.md＋frontmatter）。同じ仕様を採用するOpenAI Codexのawesome-codex-skillsとも相互運用しやすい。

3エコシステムの位置関係

mattpocock skillsの強みは「プロセス品質」、awesome-codex-skillsの強みは「SaaS連携」、cloudflare/skillsの強みは「プラットフォーム適合」と整理できる。社内ポリシーや業務ドメインに応じて、3つを組み合わせて使うのが現実的だ。

/grill-with-docsが現場で何を変えるか——実装直前のダイアログ

/grill-with-docs の効果を抽象的に語っても伝わりにくいので、典型的な発話の流れを追っておく。

エンジニアが「決済リトライ機構を追加したい」とエージェントに依頼したとする。/grill-with-docs を起動すると、エージェントは即実装に入らず、次のような問いを順に投げる。

• 「決済プロバイダは Stripe？ Adyen？ 自社実装？」
• 「リトライの起点は何？ 4xx だけ？ 5xx も？ ネットワーク例外は？」
• 「Idempotency Key を発行するモジュールはどこに既にある？ 既存の materialization cascade（CONTEXT.md 由来の語彙）と衝突しない？」
• 「ユーザーへの通知は誰の責務？ どのモジュールがオーナー？」
• 「失敗が連鎖した場合の上限と、Dead Letter Queue 的な受け皿はどこ？」

これらの質問はすべて、READMEに書かれた「ドメインモデルとの整合」「既存ユビキタス言語との整合」「責務境界の明示」を順に詰める設計になっている。回答が固まると、エージェントは CONTEXT.md を更新し、docs/adr/0042-payment-retry-policy.md のような ADR を起票し、その後で初めてコードに着手する。

Mattのリポジトリ外の例として、course-video-managerリポジトリの CONTEXT.md 差分も READMEで紹介されている。「lessonをfile systemに置く」という冗長な表現が「materialization cascade」の一語に置き換わるだけで、以降の会話・テスト名・関数名がすべて短く・一貫する。これは半年単位の累積効果として効いてくる。

Vibe Coding系フレームワーク（GSD・BMAD・Spec-Kit）との対比

READMEで明示的に名指しされる GSD・BMAD・Spec-Kit などの「プロセス所有型フレームワーク」と、mattpocock skillsの違いを整理しておく。

GSD（Get Stuff Done）系は、人間が指示するよりもエージェント側がプロセスを駆動する設計になっており、要件定義→実装→検証→デプロイまでを一気通貫のテンプレートで回す。短期間の試作には強いが、要件のズレや既存コードとの整合性は後追いで露呈しやすい。BMAD（Behavior-Driven／Model-Driven Agentic Development）系も同様で、シナリオ起点の自動進行を強みにする一方で、途中での軌道修正の手間が大きい。Spec-Kit系は仕様駆動の堅さがある分、運用ドキュメントの肥大化が課題になる。

mattpocock skillsは、このトレードオフに対して「フレームワーク自体を持たず、各失敗モードを潰すスキルだけを用意する」というスタンスを取る。プロセスの主導権は人間側に残る一方、AI が引き起こしがちな具体的失敗だけを構造的に防げる。READMEでMattが「small, easy to adapt, and composable」と強調するのは、そういう設計の自由度を意識した結果だ。

実際の選択は二者択一ではなく、「短期スパイクはGSD／BMAD、本流の継続開発はmattpocock skills」のような併用が現実的だ。BMADで素早くプロトタイプし、/improve-codebase-architecture で泥団子を解消しながら本流に取り込む、というワークフローはハマる。

Codexで動かすときの注意点

mattpocock skillsをCodexに移植したい場合、SKILL.md自体は流用可能だが、次の3点だけ注意したい。

1. 配置パス：Claude Codeでは .claude/skills/、Codexでは $CODEX_HOME/skills/ 配下に置く
2. /setup-matt-pocock-skills の再実行：CodexとClaude Codeで設定ファイルパスが異なるため、エージェント単位で初期化スキルを動かす
3. GitHub／Linear連携の認証：Mattのスキルは gh CLIに依存する箇所があるため、Codexハーネス側で認証情報の引き渡しを確認する

これらを踏まえれば、Codex CLI でも /grill-with-docs・/tdd・/diagnosing-bugs の主要ループはそのまま走る。なお現在のREADMEは、Codexネイティブのプラグイン化を検討中としてリポジトリ内のADR（.agents/adr/0002-ship-as-a-claude-code-plugin.md）を参照先に挙げている。

社内導入の落とし穴と運用設計のコツ

mattpocock skillsを実プロジェクトに広げる際の落とし穴と、それを避けるためのコツを整理しておく。

落とし穴1：すべてのスキルを一気に有効化する

/grill-with-docs・/tdd・/diagnosing-bugs・/to-spec・/improve-codebase-architecture を全部同時に走らせると、エージェントの応答が冗長になり「Skills For Real Engineers」のクレドと矛盾する。ロールアウトは段階的に進めるのが鉄則だ。

Week 1：/setup-matt-pocock-skills + /grill-with-docs のみ
Week 2：+ /tdd（new feature 用）
Week 3：+ /diagnosing-bugs（バグ発生時のみ）
Week 4：+ /improve-codebase-architecture（週1の定例で）

最初の1週間で /grill-with-docs だけ徹底的に使い、CONTEXT.md の整備と docs/adr/ の運用を社内に定着させる。これが回らないうちに /tdd を入れても、ユビキタス言語不在のままテストを書くことになり効果が薄い。

落とし穴2：CONTEXT.mdの肥大化

/grill-with-docs を回すとCONTEXT.mdが急速に膨らむ。READMEのTipsには明示的に書かれていないが、運用では 「リファクタリング義務」 を別途持たせる必要がある。月1で CONTEXT.md を見直し、使われていない用語を削除し、新しい用語を追加する運用を作っておく。

落とし穴3：2つの導入ルートを混ぜてスキルが二重になる

現在のREADMEは、Claude Codeプラグイン（claude plugins install mattpocock-skills）と skills.sh（npx skills@latest add mattpocock/skills）という2つの入口を用意し、「両方入れると全スキルが二重になる」 と明記している。チームで配布手順を決めずに各自が好きな方を入れると、同じスキル名が重複した状態の人とそうでない人が混在する。社内ポリシーとして「プラグイン（更新を購読する）」か「skills.sh（自分たちで編集する）」のどちらかに寄せ、その理由まで含めて先に決めておくのが安全だ。

落とし穴4：チーム内の運用バリエーションを揃えない

エンジニアが個別に好みのスキルだけを使い始めると、コードベースに残るアウトプット（CONTEXT.md・docs/adr/・PRD・Issue）の粒度がチーム内でバラつき始める。Mattの設計はチーム単位で運用されてはじめて累積効果を生む構造のため、社内Wikiやランチームミーティングで「使うスキルの順番」「PRDテンプレートの形」「ADRの粒度」を統一しておきたい。

ありがちなのが、新メンバーがオンボーディング時に /grill-with-docs を経由せず実装を始めてしまうケース。レビュー側で「PRDはどこ？」と毎回聞くより、PR テンプレートに「/grill-with-docs で更新した CONTEXT.md／ADR の差分」セクションを追加し、構造的に強制する方が早い。スキル運用の習慣化は仕組みで支える、というのがMatt自身の発信からも一貫した姿勢だ。

落とし穴5：/git-guardrails-claude-codeを入れずに事故る

社内導入の現場で最もよく起きるのが、エージェントによる予期せぬgit操作だ。/git-guardrails-claude-code は push / reset --hard / clean などをhookで止める防御策で、最初に入れる価値が高い。チームに展開する前にこれを必須化しておくと、リカバリ不能なインシデントの大半を防げる。

採用が伸びた背景：Total TypeScriptブランドと配布モデル

mattpocock skillsが3ヶ月で5万★を超えた背景には、Matt Pocock氏自身のブランドエクイティも大きい。Total TypeScriptという教育サービスを通じて、TypeScriptコミュニティ内で「型の薄い使い方／厚い使い方」「abstraction is a tool, not a goal」など、抽象化に対する慎重なスタンスをコンスタントに発信してきた実績がある。これらの主張は本リポジトリの「プロセスを奪わない」「small, easy to adapt, and composable」というクレドに直接接続している。

加えて、npx skills@latest add <repo> というインストール体験は、「リポジトリをクローンして手動コピー」という従来のClaude Code Skills導入と比べて摩擦が圧倒的に少ない。skills CLI 自体がスキル選択とエージェント連携を対話で取り回すため、Claude Code 初心者でも10分以内に試せる。Newsletterへの誘導まで含めた配布体験の設計が、純粋な技術的価値以上に拡散を後押ししている。

まとめ・FAQ——mattpocock skillsを最大化する次の一歩

mattpocock skillsの真価は、個別スキルの便利さではなく、「AIエージェントが失敗する4つの理由」を構造的に潰す設計思想 にある。/grill-with-docs でアラインメントを取りつつ CONTEXT.md にユビキタス言語を蓄積し、/tdd と /diagnosing-bugs でフィードバックループを縛り、/to-spec と /improve-codebase-architecture で泥団子化を防ぐ。この4本柱が揃って初めて「Skills For Real Engineers」が成立する。

導入の第一歩としては、次の3つを推奨する。

1. npx skills@latest add mattpocock/skills で導入し、/setup-matt-pocock-skills で初期化
2. 1〜2週間 /grill-with-docs だけを徹底し、CONTEXT.md と docs/adr/ の運用を定着
3. 慣れてきたら /tdd・/diagnosing-bugs・/improve-codebase-architecture を段階追加

awesome-codex-skillsと組み合わせるとClaude Code／Codex 両エコシステムをカバーできるので、複数CLIを使うチームには相性が良い。Matt Pocock skills を入口に、Claude Code skills 実践のループ全体を整える発想がフィットする。

特にプロダクトチームとしてmattpocock skillsを採用するなら、「設計判断の航跡を残す文化」 を一緒に育てることをおすすめしたい。CONTEXT.md と docs/adr/ がチームに定着すると、半年後・1年後に新メンバーがJoinしたときに「過去の意思決定を辿れる」という資産が積み上がる。AIエージェントの加速力と、人間中心の設計判断資産が両立する状態こそが、Skills For Real Engineersのクレドが目指すゴールだ。

mattpocock skillsはこの先も、Newsletter経由で新しいスキルや更新情報がアナウンスされる予定だ。リポジトリをWatchして新規スキルの追加を追いかけつつ、自社のCONTEXT.mdとADR運用に組み込んで継続的に磨いていくと、AI コーディング時代の長期競争力の積み上げに直結する。「個別スキルを使いこなす」のではなく「設計思想を社内文化に組み込む」という視点で運用するのが、最大の投資効率を生む。

最後にひとつ強調しておきたいのは、mattpocock skillsは「銀の弾丸」ではないという点だ。Mattの方法論は「数十年にわたるソフトウェアエンジニアリングの蓄積を、AIエージェント時代のスキルに翻訳した」ものに過ぎない。逆に言えば、PragmaticProgrammer・DDD・XP・A Philosophy of Software Designの古典的な原則を理解せずにスキルだけを真似ても、表層的な改善に終わる可能性がある。スキル導入と並行して、原典の引用元（READMEで言及されている書籍群）にも目を通しておくと、各スキルの設計意図が腑に落ちる。「Real Engineering」というクレドが含意する重みは、書籍を経由してはじめて完全に伝わってくる。AI エージェントとの協働を一過性のブームで終わらせないためにも、ここで紹介した設計思想と原典の両方を、自分の運用文脈に結び付けて咀嚼してみてほしい。

Q1. 既存の mattpocock/skills 解説記事との違いは？

A. mattpocock/skills完全ガイド は、現在の41スキルの構成・2つの導入ルート・呼び出し方を扱う「カタログ」型の記事だ。本記事は同じリポジトリを 「設計思想と4大失敗モード」 の角度から再評価し、担い手スキルの入れ替わりまで追う位置づけ。両方を読むと「何が入っていてどう使うか」と「なぜそう作られているか」の両側から理解できる。

Q2. 昔の記事で見たスキル名が動かないのはなぜ？

A. リポジトリの再編でスキルが改称・統合・非推奨化されているためだ。/caveman と write-a-prd 系は現在のツリーに無く、/diagnose は /diagnosing-bugs へ改称、ubiquitous-language・request-refactor-plan・qa・design-an-interface は skills/deprecated/ へ移された。4大失敗モードという枠組みは変わっていないので、コマンド名ではなく「どの失敗を潰したいか」から現在のスキルを引き直すのが確実だ。

Q3. CodexやCursorで動かすには？

A. SKILL.md仕様自体はほぼ共通のため、配置パスを書き換えれば動く。Codexは $CODEX_HOME/skills/<name>/、Cursorは ~/.cursor/skills/<name>/。gh CLI 依存スキル（/triage・/to-tickets）は、各エージェントのハーネスでCLIを呼び出す権限を確認する必要がある。

Q4. /improve-codebase-architecture はどれくらいの頻度で使うべき？

A. READMEの推奨は「数日に1回」だ。実運用では週1〜2回の定例として組み込み、結果を docs/adr/ に新規ADRとして残すのが回しやすい。CONTEXT.md の更新と組み合わせて運用すると、過去の決定が時系列で追える「設計の航跡」になる。

Q5. mattpocock skillsを使うとClaude Code以外のスキル管理は不要になりますか？

A. ならない。mattpocock skillsは「プロセス品質」に特化しており、SaaS連携（Slack／Linear／Notion）はカバーしていない。実アクションを伴う部分は、Composio系の awesome-codex-skills や awesome-claude-skills のような「連携先を集めた」スキル集と組み合わせるのが最短だ。いずれも SKILL.md 仕様は互換のため、スキル単位で混在させても問題なく動く。

Q6. ソロ開発者でもmattpocock skillsの効果は出ますか？

A. 出る。むしろ自分が忘れてしまう「アライメント・ユビキタス言語・テスト粒度・全体設計」の観点を、エージェント側が代行して問い直してくれる効果が大きい。ソロ開発で CONTEXT.md を継続更新するモチベーションは尽きやすいが、/grill-with-docs を呼ぶ習慣ができるとそこが自然と続くようになる。チーム前提で設計されたツールが、ソロでも「自分対自分の議論」を回す仕組みとして機能する好例だ。

Q7. PRやIssueの記述スタイルを縛らない方がよいのでは？

A. mattpocock skillsの設計は「縛りすぎず、構造だけ揃える」点でバランスを取っている。PRDテンプレートやADRフォーマットが固定化されすぎると、メンバーが書く前提を忘れて形式だけが残る。READMEでも「small, easy to adapt, and composable」を強調しているように、各スキルは小さく独立しているため、自社のテンプレートと組み合わせて運用しやすい。ガチガチに固めず、最低限の骨格だけ揃えるのが推奨だ。

参照ソース

• mattpocock/skills（GitHub）
• mattpocock/skills README
• skills npm package（インストーラ）
• Skills For Real Engineers Newsletter
• The Pragmatic Programmer（Hunt/Thomas）
• Domain-Driven Design（Eric Evans）
• A Philosophy of Software Design（John Ousterhout）