📓
第1章：設計って“正解がない”から難しい──でもそれが面白い
第1章：設計って“正解がない”から難しい──でもそれが面白い
本記事は『データ指向アプリケーションデザイン（DDIA）』第1章を読みながら考えた、自分なりの理解と設計視点をまとめた読書メモです
専門的な要約というより「読んで考えたことのログ」に近い形式です
図1: データモデル3種類 (Relational / Document / Graph)
用語の説明がメイン、でも油断できない
書いてある内容は、いわゆる“設計寄り”な仕事をしてる人なら一度は耳にしたことあるワードばかり
信頼性、保守性、パーセンタイル、レイテンシ、スループット…
でも本質は、「これってシステム全体の話ですよ」っていうメッセージ
スループットとか、文脈で意味変わるのに使いがちでちょっと怖い
たとえば、ある業務における「1件」は何をもって1件なのか？
処理数？ユーザー数？バッチ単位？…コンテキスト依存すぎる
「スループットたまによくわかんなくなる」って自分で思うことあるけど、それ正しい反応だと思う
メンテナンス性、軽視すると詰む
「とりあえず動く」が積み重なっていった結果、
ある日リプレイスを余儀なくされたときに詰んでることに気づく
問題が表面化したときにはもう遅い。だから設計初期の意識づけが重要
正しさは未来予測にすぎない
この辺り、読んでて思ったのは「設計って予測なんだよな」ってこと
- 将来こうなると思って今の決断をする
- でも現実は変わるから、「違ったわ」も発生する
つまり、「誤りを前提とした設計」が必要になる
だからこそ、「判断を変える勇気」と「変えられる構造」が大事
失敗を恐れるより、リカバリ可能性を担保しておく設計力が問われてる感じがする
複雑さには2種類ある、という視点が大事
- 業務の複雑さ（たとえば制度、ルール、例外処理…）
- ツールの複雑さ（Kotlin、Rustとかマイクロサービスとかクラウドとか）
どっちかだけを見てても設計は成立しない
そして、前者は変えられないことが多い。だからツール選定で調整する
あと、「偶発的な複雑さ」と「本質的な複雑さ」の話
“偶発的”のことを“偶有的”って書いてる本もあるけど、どっちも要は 「本来なくてもいい複雑さ」 って意味だよね
✍️ まとめ：この章は“設計者としての視座”を揃える回
1章は、用語の整理に見えて実は 「設計に取り組む覚悟」を問われる回
- 自分の判断が将来どう変化に晒されるか？
- そのときに 設計者として何を信じ、どこまで割り切るか？
それを最初に突きつけてくる章でした
💡 設計Tips
- 設計は「正しさを証明すること」ではなく、「予測が外れたときの対処力」が問われる
- スループットや可用性などの指標は“定義が先”！コンテキスト抜きでは語れない
- 「設計者としての勇気」と「割り切る力」が本当に必要なのは、判断が変わった“その後”
Discussion