ハクソク

世界を動かす技術を、日本語で。

設計圧力: あなたのコードを形作る見えない手

365日前原文(hynek.me)

概要

  • コード設計 における違和感や「設計が崩れる」現象の背景説明
  • Design Pressure という見えない力がアーキテクチャに与える影響
  • PyCon US 2025 での発表内容や追加資料の紹介
  • 参考となる記事・動画・書籍リストの提供
  • Hynek Schlawack による関連情報・サポート案内

Design Pressure: コードを形作る見えない力

  • 直感的な違和感 や「なぜか設計が崩れる」現象の原因、Design Pressureという概念による説明
  • ベストプラクティス を守っても設計が歪む理由の考察
  • PyCon US 2025 （Pittsburgh, USA）での発表内容紹介
  • SpeakerDeck でスライド公開
  • 発表時の体調不良（声枯れ）エピソード

追加資料

  • 発表で直接参照したが、時間の都合で割愛した 推奨資料 リスト
  • ソフトウェア設計全般 に関する記事・動画・書籍の紹介

推奨記事

  • Types of Coupling by Ben Orenstein：結合の種類
  • Attractive nuisances in software design by Paul Ganssle：設計上の落とし穴
  • Designing with types: Making illegal states unrepresentable by Scott Wlaschin：型による安全性向上
  • The Vietnam of Computer Science by Ted Neward：ORMに関する問題指摘
    • Jeff Atwood による要約も参考
  • Approximating Sum Types in Python with Pydantic by William Woodruff：PythonでのSum Type表現
  • How I Build by Adam Montgomery：設計方針の共有
  • DTOs & Mapping: The Good, the Bad, and the Excessive by Derek Comartin：DTO利用のトレードオフ
  • The Typestate Pattern in Rust by Cliff L. Biffle：Typestateパターンの紹介
  • Writing Python like it’s Rust ：Rust的Pythonコーディングスタイル
  • What Color is Your Function? ：async関数の設計哲学
    • ORMやPydanticクラスの「色」による挙動差への注意喚起
  • Amundsen’s Maxim ：Web API設計における各モデルの違い

推奨動画

  • Integrated Tests Are A Scam by J.B. Rainsberger：統合テスト批判
  • The Deep Synergy Between Testability and Good Design by Michael Feathers：テスト容易性と設計の相乗効果
  • SOLID Principles? Nope, just Coupling and Cohesion by Derek Comartin：結合度・凝集度重視
  • The Rising Sea by Matthew Drury：設計の変遷
  • Advent of Code ：コーディングイベント
  • Łukasz Langa’s Keynote PyCon US 2022 ：キーノート講演
  • Simple Made Easy by Rich Hickey：シンプルさの本質
  • Building Protocol Libraries The Right Way by Cory Benfield：Sans I/Oの紹介
  • Functional Core Imperative Shell by Gary Bernhardt：ビジネスロジックの分離
  • Domain Modeling Made Functional by Scott Wlaschin：関数型ドメインモデリング

推奨書籍

  • Tidy First? by Kent Beck：設計整理のすすめ
  • Architecture Patterns With Python by Harry Percival and Bob Gregory：Pythonアーキテクチャ解説
  • Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans：DDDの集大成

コロフォン・クレジット

  • ポストカード to Ireland、Theodor Fontaneの引用
  • 1923年のスクリーンショット 利用
  • Frinkiac でのSimpsons GIF、 Giphy でのGIF利用
  • 講演依頼 やコンテンツ支援の案内

Hynek Schlawack プロフィール・サポート案内

  • Python、Go、DevOps を愛するCode Bohemian
  • Blogger、Speaker、YouTuber、PSF Fellow
  • 寄付・サポート による活動継続のお願い
  • Hynek Did Something ニュースレターの紹介

ソフトウェア設計の「見えない圧力」への理解

  • 設計圧力（Design Pressure） がコード・アーキテクチャに及ぼす影響
  • 理想と現実 のギャップ、設計の歪みの根本原因
  • 型安全性、結合度、凝集度、I/O分離 などの観点からの設計改善
  • 参考資料・コミュニティ知見 の活用による設計力向上

Hackerたちの意見

[動画]

attr.ibとattr.sが良いアイデアだと思ってる人からデザインのアドバイスを受けるのはどうかと思うけど、彼がDDDが空虚なカルトだって指摘してるのはその通りだね。

└

DDDは特に最初のフェーズではいいね。すべての概念は実際には以前の原則を再利用したものだし、全く新しいものはないよ。

└

"attr.ibとattr.sが良いアイデアだと思ってる人からデザインのアドバイスを受けるのはどうかと思うけど" 詳しく教えてもらえる？

└

DDDを批判する前に、パターン病と過剰なOOP化を指摘したいね。確かに後者は行き過ぎることもあるけど、前者の2つはもっと頻繁に乱用されてる。幸い、パターンの狂気はかなり収まってきたけどね。

自分はキャリアの中で、OPが言うデザインプレッシャーを育ててきた。コードやその形の主なドライバーだと思ってる。成功するアーキテクチャの最も重要な側面だし、完全に直感に基づいてるから、銀の弾丸はないんだよね。意図的に良いプラクティスを持ってる人でも、デザインプレッシャーの感覚がないとそれをダメにしちゃうのを見てきた。デザインプレッシャーの感覚は一種のセンスだと思うし、味覚と同じで育てる必要がある。簡単に言葉にしたり測ったりできないんだよね。自分のアーキテクチャが有利な特性を持つことは分かるけど、それを説明するのにはすごく労力がかかる。目指すべきは、アーキテクチャを見て、他の人がそれを使っていく中での失敗状態を見えるようにすること。外部からのプレッシャーや要件の変更など、2年、3年、10年先を見越して進化していく過程でね。自分がアーキテクトだったプロジェクトの元同僚と連絡を取り合って、アーキテクチャがどう進化したのか、どんな痛点があったのかを学んでる。そういう感覚を持ってる他のアーキテクトと仕事をするのは楽しいし、いい雰囲気が生まれる。一方で、「ベストプラクティスかそれ以外か」みたいな人たちは本当に耐えられない。そういう人たちと関わらなくて済むようにしてるよ。

└

これはデザインパターンの説明における「力」の概念を思い出させるね。特定のデザインパターンを使うかどうかを決めるためには、そのパターンが使われる特定の文脈での力を評価して、重み付けしなきゃいけないんだ。力と呼ばれるのは、デザインを特定の方向に引っ張るから。単に「圧力」との物理学的な比喩が違うだけだね。

└

コードは主に人間とのコミュニケーションのためのもので、機械で動かす必要があるけどね。すべてのパターン、原則、ベストプラクティスは、他の人、つまり未来の自分が理解しやすくするためのものなんだ。柔軟性は重要だけど、共通のパターンや共有されたメタファーは素晴らしい効果を発揮するよ。

└

『禅とオートバイ修理技術』は良い参考になるよ。また、実際にどんなゲームが行われているのかを思い出すのも大事だね。誰かが特定の「ベストプラクティス」を広めるとき、彼らは何を考えているんだろう？多くの場合、アンクルボブタイプの人たちは自己宣伝の一環としてやってるだけだよ。ほとんどのベストプラクティスは根本的に擁護できないもので、彼らの小さな教会が脅かされると、個人攻撃に走るんだ。

いいトークだった！共感できる部分がたくさんあったよ。このテーマは多くのトレードオフがあって、扱うのが難しいと思う。一つ言及されていなかったのは時間的な側面だね。多くの場合、最初は「データベース指向の設計」（ちょっとネガティブな意味で）から始めるのが理にかなっている。つまり、Postgresのデータに合わせた形の型を使うってこと。でも、時間が経つにつれてドメインへの理解が深まると、そのアプローチの限界に気づくようになる。その時点で、別のドメインモデルを導入して明示的なマッピングを使うのが理にかなってくる。でも、いつその切り替えをするかを見極めるのは簡単じゃないよね。最初からドメインモデルを使うべきなのか？それもありかもしれないけど、リスクがある。SQLテーブルにあるものよりも、実際にドメインをうまく表現できないドメインオブジェクトができちゃうかもしれないし。最初は、ドメインモデルとSQLのSELECT行、JSONレスポンスボディの間を行き来するのが不自然に感じるし、チーム内でも正当化しにくいよね。だから、ドメインモデルから始めるのではなく、ドメインをより理解した後にリファクタリングしていくのがベストかもしれない。抽象化は少なめか全くしない方がいいけど、「具体化」が多すぎて痛みを感じたら、抽象化を導入するのをためらわないで。結局、判断が必要だから教えるのが難しいんだよね（このトークはその点をうまく指摘していると思う）。

└

ちょっとナイーブな質問だけど、「ドメインモデル」とこれらのもっと原始的なデータ表現の違いって何？この用語はよく使われてるけど、実際に何を意味しているのか理解できないんだ。ドメインモデルって、科学者が理論と呼ぶようなものを指してるの？ドメインの基本的な概念、相互関係、振る舞いなどを説明するもの？仕様書みたいな感じ？もちろん、具体的な実装がたくさんあったり、データで表現する方法もいろいろあるよね。ここで混乱するのは、データをドメインモデルにマッピングするってどういうことなのか分からないから（実際のコードエンティティ？）、多分考え方が間違ってるんだと思う。

└

最初からドメインモデルを使うべき？多分そうだけど、リスクもあるよね。SQLテーブルにあるものよりもドメインをうまく表現できないドメインオブジェクトができちゃうかもしれないから。最初からドメインモデルを使うべきだよ。絶対に必要なら、type User = PostgresUserみたいなタイプエイリアスを使ってショートカットすることもできるけど。だけど、他のコードの中でpostgres-typesを使うのは絶対にダメだよ。後でひどいリファクタリングを招くだけだから。 > ドメインモデル、SQLのSELECT行、JSONレスポンスボディがほぼ同じなら、行き来するのはちょっと気まずいし、チーム内で正当化するのも難しいよね。絶対にダメだよ。これは世界で最も普通のことだから。実際、最初は同じじゃないし。ちゃんとしたカレンダーや日付時刻のタイプ、わかりやすい名前を使いたくないの？少しは構造を整えたいと思わない？IDには本当に適切なタイプを使うべきだよ。User(name: string, posts: string[])は最悪だ。User(name: UserName, posts: PostId[])は許容できる。だから、ほとんどのトリビアルなケースでも何らかのマッピングをしなきゃいけないよ。

ここにSQLModelを暗にディスってるってコメントがあったけど、返信しようと戻ったら消えてた。変だね。暗に言及されているから、スライドの中では見つけられなかったよ。

└

あのコメントを書いた後、すぐに削除しちゃった。オープンソースプロジェクトについて公にネガティブなことを言いたくないんだ。みんながすごく頑張って作って維持しているプロジェクトだからね。元のコメントがそのラインを越えちゃった気がした。とにかく、そのトークにはPydanticとSQL Alchemyのロゴが入ったスライドがあるよ。私の知る限り、この二つを結びつける（そこそこ人気のある）ライブラリは一つだけだと思う。スピーカーは、データ、ドメイン、API、その他のモデルは関連しているけど、別々であるべきだという説得力のある主張をしていると思う。

トークの一部が、https://www.amundsens-maxim.com/を思い出させるな。

└

ああ、その話をやってる時にそれを見ておけばよかった！リソースに追加するね！

1ヶ月前に逆の問題があったよ。既存のデータもドメインモデルもAPIもないグリーンフィールドプロジェクト。APIや永続層をドメインモデルとは違う風にモデル化する理由がなかったから、同じクラスを3回実装して、さらに2つのマッピングを追加した。何のために？まあ、いつかAPIの利用者や既存のデータが出てきて、当時のシステムを変更する必要が出てくるからね。

面白いね、現代の便利さがカップリングを促進してるのかも。シングルモニターでLSPを無視してるサバンナがたくさんいるのも納得だわ。

こういうプレゼンテーションを記事として再構成してほしいと思うことは確かにある。YouTubeのトランスクリプトを引っ張り出そうとしたけど、アサイドやジョーク、そして「えーと」とかがあって、群衆の前で話すときのネイティブな特徴だけど、長い文章にするとただのノイズになっちゃって読みにくかったよ。

└

それ、AIがなんとかしてくれそうじゃない？LLMにはぴったりな気がするんだけど。--- ちなみに、私が話してる人なんだけど、正直言うと最近は全然やる気が出ないんだよね。昔はブログ記事をたくさん書いて、反響のあったものをCfPsに提出してたんだけど（例: https://hynek.me/articles/python-subclassing-redux/> → https://hynek.me/talks/subclassing/>）。でも今は、TwitterやGoogleの最近の変化のおかげで、私の作品を多くの人に読んでもらうチャンスはHNのフロントページに載ることだけで、これはまるで宝くじみたい。ひどい状況で、アルゴリズムの輪に乗るためにYouTubeも始めたくらい。こうやって自分の考えをまとめて表現するのはすごく大変なんだよね。大きなカンファレンスで話すことができれば、少なくともリアルな面白い交流ができるから、それは私にとって大事なんだ。私は内向的だからね。今、私たちが公共のウェブを殺してしまっているのは、本当にまずいことだと思う。

└

これがGemini 2.5 Proで整理してみたものだよ： https://rentry.org/nyznvoy5 YouTubeのリンクをAI Studioに貼り付けて、これをプロンプトにしたんだ。もし試したいなら：このトークを記事として再フォーマットして。うーんやあーは削除して、要約はしないで、文脈は実質的に同じにして。スライドの内容も可能なら含めてね。