【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ

【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ

「うちはクリーンアーキテクチャです」と言われて、リポジトリを開いた。
フォルダは美しく、処理も追える。でも、なぜこれが良い設計なのかは分からなかった。
尋ねても、返ってくるのは「そういう設計になっているから」。

そんな経験のある方へ。分からなくて、正解です。
設計の「なぜ」は、ググっても出てきません。
コードにもREADMEにも書いてありません。
答えを知っているのは、その形を決めた人だけです。

この資料では、決めた人に聞いてみる最初の質問をひとつ紹介します。
「この形って、お客さんのどんな仕事から来てるんですか？」。
答えに仕事の話が出てくるか、それとも教材の名前が出てくるか。
そこから、設計の見え方が変わり始めます。

コードは出てきません。専門用語も使いません。
足りなかったのは経験ではなく質問だった、という話を、連載（全4回）の入口としてお届けします。

DDD本を途中で閉じた経験のある方も、どうぞ。

記事一覧

【 設計編 #1 】　「ドメイン駆動」と「実装駆動」ってなに？

`軽量DDD` `設計判断の出発点` `DDDの肯定形の対義語`

https://speakerdeck.com/panda728/yasasikujie-shuo-domeinqu-dong-to-shi-zhuang-qu-dong-tutenani-she-ji-noxing-wojue-meru2tunochu-fa-dian

【 設計編 #2 】　持ち主の寿命のはなし

`所有性` `依存先の寿命` `公共構造（SQL・HTTP）とベンダー製品`

https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-2-chi-tizhu-noshou-ming-nohanasi

【 設計編 #3 】　規約による保護と、構造による保護

`ポカヨケ` `型と制約で守る` `人依存の規約は最下位層`

https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-3-gui-yue-niyorubao-hu-to-gou-zao-niyorubao-hu

【 設計編 #4・本編最終回 】　何があなたの手を動かすのか

`変更理由の出所` `単一責任原則の「責任」` `要求の駆動源`

https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-4ben-bian-zui-zhong-hui-he-gaanatanoshou-wodong-kasunoka

Transcript

1. DDDのコード、 読めるのに分からない人へ 分からないのは、経験が足りないわけではない 2026.07 北尾　英之 (@kitaohx) 1
2. こんな悩み 『うちはクリーンアーキテクチャです』と言われて、 　リポジトリを開いた。 　フォルダは美しい。処理も追える。動きも分かる。 　項目をひとつ足すのに、ファイルを5つ触った。 　なぜこれが良い設計なのかは、分からなかった。 尋ねても、返ってくるのは「そういう設計になっているから」 。 と び ら 2
3. 分からなくて、正解です。 　探している答えは、そもそも 　リポジトリに入っていません。 3
4. ググっても「なぜ」は出てこない クリーンアーキテクチャの解説なら、検索すれば出てきます。 　AIに聞けば、一般論は説明してくれます。 でも「このリポジトリが、なぜこの形なのか」は、 　ネットを探してもAIに探させても出てきません。 書かれていない情報は、検索できません。 か ら く り 4
5. コードにも、書かれていない src/ ├ Domain/ ├ Application/ ├ Infrastructure/ └ Presentation/ お客さんの仕事 に合わせて作った設計も、サンプルの写経も、 　フォルダ構成は同じです。 コードを読んで分かるのは、 「何をしているか」まで。 　なぜこの形にしたのかは、どのファイルにも書いてありません。 か ら く り 5
6. 実は中身の抜けた実装は珍しくありません。 「形だけ真似て、中身が抜けた」 　この失敗には、名前があります。 「軽量DDD」 。 　そんな名前がつくほど、よくあることだったのです。 目の前のリポジトリを見ても分からないとき、可能性は二つあります。 お客さんの仕事 から作られていて、中身は ある 形は立派でも、中身が 抜けている READMEにもwikiにも、どちらなのか書いてません つ ま ず き 6
7. 読む相手を、コードから人に変える 読む時間を増やしても、入っていないものは見つかりません。 答えを知っているのは、決めた人です。では、こう聞いてください。 「この形って、お客さんの どんな仕事 から来てるんですか？」 仕事 から作られた設計なら、答えに仕事の話が出てきます。 　 「締めが月末だから」 「返品の扱いが特殊だから」 写経なら、教材の名前 が出てきます。 た ね あ か し 7
8. 実は、最初にこの質問をしていました 最初の場面を、思い出してください。 「なぜこの設計なんですか」と、もう尋ねていました。 　返ってきた答えが、これです。 「そういう設計になっているから」 お客さんの仕事 が、出てきません。 　これが、ひとつめの判断材料です。 た ね あ か し 8
9. ただし、その答えのみで、決めつけない 先輩は、締切の直前だったのかもしれません。 　たまたま、決めた本人ではなかったのかもしれません。 答えひとつでリポジトリ全体を判定するのは、早すぎます。 公平に確かめるには、まだ質問が足りません。 だ い じ な 注 意 9
10. 質問を、あと3つ用意しました # 質問 たとえ話 1 仕事の話から？　道具の話から？ 包丁 2 持ち主は、システムより長生き？ 地面と足場 3 張り紙を読まなくても守れる？ テプラ 4 運転席に座っているのは誰？ 運転席 1問目は、先ほど挙げたものです。 　残りの3問を含め、連載【やさしく解説 設計編】 （全4回）でご覧いただけます。 み ち す じ 10
11. 足りなかったのは、経験ではなく質問 業務経験を積むまで、待つ必要はありません。 　これらの質問があれば、今日から動けます。 なお、この連載にコードは出てきません。専門用語も使いません。 　1回にひとつずつの質問を、たとえ話を使いながら進めていきます。 連載を終えたら、先ほどのリポジトリに戻ってみてください。 　 「そういう設計だから」の先を、自分で確かめられるようになります。 み ち す じ 11
12. コードが難しいのではない。 　答えが、リポジトリの外にある。 12
13. まずは#1の、包丁の話から。5分で読めます。 https://speakerdeck.com/panda728/yasasikujie-shuo-domeinqu-dong-to-shi- zhuang-qu-dong-tutenani-she-ji-noxing-wojue-meru2tunochu-fa-dian DDD本を途中で閉じた経験のある方も、得るものがあるはずです。 さらに、SOLIDとクリーンアーキテクチャを読み直す中級編（全6回）も登場予定。 是非ご覧ください。 13
14. 記事一覧 【 設計編 #1 】　「ドメイン駆動」と「実装駆動」ってなに？ 軽量DDD 設計判断の出発点 DDDの肯定形の対義語 https://speakerdeck.com/panda728/yasasikujie-shuo-domeinqu-dong-to-shi- zhuang-qu-dong-tutenani-she-ji-noxing-wojue-meru2tunochu-fa-dian 【 設計編 #2 】　持ち主の寿命のはなし 所有性 依存先の寿命 公共構造（SQL・HTTP）とベンダー製品 https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-2-chi- tizhu-noshou-ming-nohanasi 14
15. 記事一覧 (つづき) 【 設計編 #3 】　規約による保護と、構造による保護 ポカヨケ 型と制約で守る 人依存の規約は最下位層 https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-3-gui- yue-niyorubao-hu-to-gou-zao-niyorubao-hu 【 設計編 #4・本編最終回 】　何があなたの手を動かすのか 変更理由の出所 単一責任原則の「責任」 要求の駆動源 https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-4ben- bian-zui-zhong-hui-he-gaanatanoshou-wodong-kasunoka 15