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

めっちゃいい講演だったね！共感できることマジでいっぱいあったよ。このトピックって、トレードオフが多いから難しいんだよね。今回触れられてなかった点として、時間軸があると思うんだ。最初はPostgresのデータの形そのまんまを型にしたような”データベース指向設計”（悪い意味でね）で始めるのが理にかなってること、結構あるじゃん？
でも時間が経ってドメインの理解が深まると、そのアプローチの限界に気づき始めるんだ。そしたら、別のドメインモデルを導入して、明示的なマッピングを使うのが多分正解。だけど、いつ切り替えるべきかっていうタイミングの見極めが超難しいんだよね。
最初からドメインモデルで始めるべき？多分ね、でもリスクもあるんだ。だって、SQLテーブルにあるやつより、ちゃんとドメインを表せてるとは言えないようなドメインオブジェクトになっちゃう可能性もあるじゃん。あと、少なくとも最初は、ドメインモデル、SQLのSELECT結果、JSONレスポンスの形がほとんど同じなのに、それらの間でいちいちマッピングするのって変な感じするし（チーム内で正当化するのも大変）。
だから、最初からドメインモデルにするより、ドメインがもっとわかってからリファクタリングで徐々に導入していくのが最良のアプローチかもしれないね。抽象化は少なめかゼロで始める方に倒しておきつつ、具体的なものだらけで辛くなってきたら躊躇なく抽象化を導入する。これもまた判断が必要だから、教えるのが難しいんだ（講演はそこを見事に指摘してたと思うけどね）。

マジで素朴な疑問なんだけど、「ドメインモデル」って、こういったもっとプリミティブなデータ表現と何が違うの？よく聞く言葉だけど、みんなが具体的に何を意味してるのか、いまいち掴めないんだ。
ドメインモデルって、科学者が「理論」って呼ぶようなものなのかな？ドメインをいくつかの根本的な概念、それらの関係性、振る舞いなんかで記述したもの？仕様書みたいな？
それはもちろん、たくさんの具体的な実装（そしてデータを表現するたくさんの方法）がありうるよね。ここで俺が混乱するのは、データとドメインモデルの間でマッピングするってのが何を意味するのか分からないってことなんだ（ドメインモデルって実際のコードのエンティティなの？）。だから、多分俺、これについて考え方間違ってるんだろうな。

ちょっと簡単な例だと、日付があるね。ISO 8601形式の文字列で保存できるし、システム間で共有される仕様だから、そうするのが理にかなってることも多い。でも、実際に表示する段階になると、ローカライゼーションやタイムゾーンみたいなたくさんの追加の考慮事項が出てくるんだ。そうなると、構成要素を分割したデータ構造が必要になるし、一部の構成要素は、最終的な表現を文字列として出力するロジックのキーやパラメータとして使われるかもしれない。
だから、ストレージ層もプレゼンテーション層も文字列だけど、それらは違うものなんだ。この両方を調和させるには、中間層が必要になる。そこにはドメインモデルとなる構造体や、それを操作するロジックが含まれるんだ。ある層から別の層へジャンプするには、データをマッピングする。この例だと、文字列から構造体、そしてまた文字列へ。
MVCやCRUDアプリだと、層ごとにモデルが似てる（特に動的言語だと同じ）ことが多いから、マッピングなんて気にしないよね。でも、ユースケースが複雑になるにつれて、ドメイン層とそこにあるモデルが変わってくるんだ。そうすると、マッピングのコードを追加する必要が出てくる。ストレージ層にはたくさんのテーブルがあるかもしれないけど（SQLを使ってる場合）、ドメイン層ではそれが単一の構造体になったり、その後、プレゼンテーション層で重複した情報を含むたくさんのモデルになったりするんだ。
NOTE
だから、多くの人がほとんどのORMライブラリが好きじゃないんだ。モデルが似てるときは素晴らしいんだけど、モデルが乖離し始めると、結局生のSQLクエリに頼る必要が出てきて、そうなるとリファクタリングが面倒になる。良いORMライブラリはメタプログラミングに依存してるけど、結局それはただの奇妙なSQLでしかない。

ORMライブラリには、そんな簡単な例のためのValue conversion機能があるよ。

いや、そうじゃないんだよね。結局は書かなきゃいけないコードの話なんだ。ORMから取得するデータ構造をいじる代わりに、ドメインロジックをよりクリーンで明確にする何かを持つのさ。データをマッピングするためのコードはシンプルだから、保守可能なユースケースロジックを持つことと引き換えに、書くための時間という対価を支払うだけなんだ。

一般的に、ある問題にとって理想的な形式は、別の問題にとってのそれとは同じじゃないんだよね。例えば、RDBMSにグラフを保存する場合、理想的な形式は多分隣接リストで、それを再帰クエリで辿るのがいいだろう。でも、アプリのコードでは、お互いを指し示すオブジェクトグラフとして持ってるのが多分一番楽だ。そして、フロントエンドのコンテキストでは、グラフなんて話したくもない。ユーザーは一つのノードの親子関係についてしか実際話せないからね。
あらゆるシナリオに理想的なデータモデルなんて一つもないんだ――だったら、シナリオごとに違うモデルを持てばいいじゃないか？そうすれば、あるモデルから次のモデルへ変換する方法だけを考えればいいし、その理想化されたデータモデルに依存するどんなロジックも、かなりシンプルに実装できるようになる（だって、それが良いデータモデルの本質だからね - それ以外のロジックはたいてい自然と決まってくる）。
だから、君が使っているデータモデルは、対象となるドメイン／主題に局所化されてるんだ。必要なときにデータをモデル間で移行させてるだけ。ドメインってのはただの任意のコンテキストさ――永続化層とか、UIロジックとか、あるいはもっと具体的で、会計士向けのUIページでデータがどう整理されるかを反映するように会計士向けのモデルを持ちたい、みたいな。だって、彼らが俺に頼んでることの30％しか理解してないから、”彼らの用語”で進めた方が、何も考えずに実装するのがずっと楽になるんだ。あるいは、この特定の関数の主な目的はレポート用の様々な集計だから、最初にデータセットを集計グループとほぼ一致する階層に整理する。適切に揃ったら、集計ロジック自体は完全に自明になるんだ。
単一テーブルのselect *を超えるクエリをデータベースに投げるたびに、新しいドメイン固有のデータモデルを作ってるんだ、とさえ言えるかもしれないね。元のテーブル表現から新しいものへ変換してるだけなんだ。
すべてのドメインモデリングは、これから書くロジックに最も合う表現を具体的に選択すること、そして、持っているモデルを欲しいモデルに変える方法を見つけ出すことなんだ。それ以外の主題については、ただの実装の詳細でしかないよ。

＞ 例えば、RDBMSにグラフを保存する場合、理想的な形式は多分隣接リストで、それを再帰クエリで辿るのがいいだろう
これは些細な点だって分かってるけど、全体のトピックに関連してると思うから、ちょっと突っ込んでみるね。
隣接リストは、RDBMSでグラフ／ツリーを保存する方法としては、多分最悪だよ。理解するのは一番簡単かもしれないけど、特にRDBMSにRecursive CTEがない場合、パフォーマンス特性が最悪クラスなんだ。これは、君が思うよりもはるかに低いスケールで問題になり始めるよ。数百万行あれば、速度低下が見え始めるのに十分だ。
この本[0]（Joe Celkoの『Trees and Hierarchies in SQL For Smarties』）には他の多くのオプションが載ってるけど、俺が好きなClosure tableアプローチ[1]は載ってないね。
そしてここで、DBとアプリケーションの間の長年の摩擦に話が戻ってくる。トリガーの話を始めると、開発者はひるむ。DBにロジックを入れたくないって言うんだ。俺が見てきたあらゆるケースで、彼らが考案する代替策は信じられないほど複雑でエラーを起こしやすいけど、まあ、DBにはないからね。トリガーを恐れる理由は全くない、ただし、コードと同じように扱うならばね（だってコードだから）：PRを介してのみ追加／修正／削除し、注意深いレビューとテストを行う。
[0]：
[1]：

俺の理解では、データベースモデルっていうのは、完全に正規化されてるもの——つまり、冗長な情報や繰り返される情報がないようにテーブルを設計すること。リレーショナルDBを勉強するときに習うやつね。
そのモデルでは、参照を辿ることでどこからでもどこへでも移動できるんだ。
一方、少なくともDDDの観点からのドメインモデルは、少なくともいくつかの点で異なるよ。ドメインクラスはビジネスの振る舞いを公開するし、特定のエンティティを隠すこともできるんだ。
例えば、注文を表す必要があるeコマースアプリケーションを想像してみて。
DBモデルでは、orderテーブルとorder_lineテーブルがあって、後者の各行が前者の行を参照する形になるだろう。でも、ドメインモデルでは、代わりに単一のOrderクラスを持っていて、注文明細はメソッド経由でのみアクセス可能で、文字列とかタプルとか、何らかの形式で持つことになるかもしれない——エンティティとしては持たない。Orderクラスはorder_lineテーブルの存在を隠蔽するんだ。
さらに、OrderクラスにはmarkAsPaid()のようなメソッドがあるだろうし、これはこのタイプの情報をどう永続化するか——enum？boolean？orderの行を参照する別のテーブル？——といった実装の詳細も隠蔽する。呼び出し側にとっては関係ないことなんだ。

俺にとってドメインモデルとは、自分がモデリングしているドメインに関する情報を、使用する型やデータ構造の中にできるだけ多く取り込むことなんだ。大抵の場合、それは不正な状態を表現できないようにUnion型を使うことを意味するんだ。例えば、データベースネイティブな方法でUnion型を保存する方法を俺は見たことがないんだ。その場合、別のドメイン層を使うことが必須になるんだ。
参考までに：

俺にとってドメインモデルは、システム内のデータとやり取りできるオブジェクト指向APIのことだね。もう一つのやり取りの方法はもちろん生のSQL呼び出しだけど、それだとユーザーはデータベーススキーマでデータがどう表現されているかを知る必要がある。一方、OOP APIを使うと、APIメソッドはいくつかの複数のモデルクラスのインスタンスを返すんだ。
異なるクラスがメソッド呼び出しによって互いに関連付けられている様子は、俺たちのシステムの「理論」のようなものを明確にするんだ。システム内にどんなオブジェクトがあって、それらがどんな操作を行って、結果として他のどんな種類のオブジェクトを返すか、などなど。だから、生態学的な生物学における「理論」にすごく似ているように見えるよ。複数の種が互いに相互作用しているようなね。

この”理論”はDB自体の中でモデル化できるよ。

ドメインモデルから始めるべきか？リスクあるけど絶対そうすべき。ショートカットはいいけどコード全体でpostgres-types使うのは後々大変だからダメだよ。
SQLとかJSONとかドメインモデルが同じならマッピング不要って？いやいや、普通は違うし、ちゃんとした型やID使うでしょ。単純なケースでもマッピングは必要だよ。

長年の経験から、最近のWeb開発はコードをDBエンジンに入れるのを避けてるだけだと思うんだ。ORMとかはデータを”外部”扱いしてるせいだよ。
怖い話だけど、いつかWeb機能付きのJavaScript DBが出てきて、伝統的なDBは終わるかも。パフォーマンスは悪くてもシンプルで生産的だから、きっと流行るよ。

それは一つの見方だね。完全に間違いじゃないのが辛いところ。
でも100％正しいとも思わないな。今のDBだと難しいこともあるし。そういう機能をDBに詰め込んでも、問題のほとんどは残って”DBレイヤー”の中にあるだけになると思うよ。

俺が考えてるのは”今ある”DBじゃなくて、エンドツーエンドのJavaScript（かWASM）の全く新しいスタックだよ。AkkaとかOrleansをReactと組み合わせた感じ。
”データ”はActorが永続化して、Actorはサーバーでもブラウザでも全く同じコードで動かせる。ActorのアドレスはHTTP URIになるから呼び出し規約が統一されるんだ。

面白そうだね。でも、結局問題の場所を移してるだけだよ。
モデルをストレージ層に近づけるのはいいけど、他のストレージ問題はなくならないし、Actor層でトランザクションとか扱うのは注意が必要だね。
JavaScriptは嫌いだけど、WASMベースなら興味あるかも。動くモデルを見てみたいね。

そうだね、デバッグも最適化もできないDBの中だね。

DBエンジンに高度な機能を入れるなら、たぶんそこそこまともなデバッグサポートも入れるだろうね（そう願いたいけど）。
でもやっぱり、問題を解決してるんじゃなくて、場所を移してるだけだよ。

君の言う通り100％その通りだよ。でも俺が何か見落としてなければ、これって（ありがたいことにJavaScriptじゃないけど）PostgREST [0]で既にやられてるんじゃない？
[0]: https://docs.postgrest.org/en/v13/

Convexを紹介するね。
https://www.convex.dev/
免責事項：僕は精神的に似てるSpacetimeDBの開発者だよ。クライアントサイドでも動かすつもりで、クライアントサイド予測に必要だからね。いつかWebレンダリングもやると思うよ。

俺は筆者の意見に反対だな．データストアはpostgres，Kafka，RabbitMQ，redis，memcache，elasticsearchとか色々あるし，HTTP APIも普通ある．全部postgresって訳にもいかない時が多いし，「コードがDBに属する」って言っても結局APIが必要．問題を後回しにしてるだけに見える．JavaScript製のDBが従来のDBを終わらせるって話は，SpacetimeDBやSparkもあるし，万能解はないから起きないと思うな．全部トレードオフだ．

KafkaとRabbitMQは別物で，混同は誤用の証拠だよ．キューならKafkaじゃないし逆も然り．
redisやmemcacheは，ちゃんとしたRDBMS（Postgres，MySQL，SQLiteとか）のチューニングで不要なことが多い．RDBMSの高性能にはみんな驚くはずだけど，大規模運用が難しいからキャッシュを前に置くのが楽なんだね．
elasticsearchも，RDBMSのFTSで十分な場合が多い．ESは管理複雑だし．

こういうプレゼンが記事形式になってたら良いのになーって時は確かにあるね．YouTubeの文字起こしを抜き出してみたけど，脇道に逸れた話とかジョークとか”えー”とかが混ざっててすごく読みにくかった．聴衆の前で話すときの自然なものだけど，長い文章になるとノイズでしかないんだよね．

AIなら文字起こし綺麗にできそうだよね？ LLMにうってつけっぽい．
―――
ちなみに俺が講演者なんだけど，正直最近は全然書く気起きないんだ．
前はブログ書いてCfPに出してたけど，最近のTwitterやGoogleの変更で，HN frontageに当たるくらいしか多くの人に読まれるチャンスが無い宝くじ状態になっちゃった．だからYouTubeにも手を出した．
考えまとめて話すのは大変だけど，講演だとIRLの交流があるのが重要なんだ（内向的な俺には）．
公共のウェブを殺して種を食い潰してるってことをもっと言いたいね．

これ，Gemini 2.5 Proで綺麗にしてみたやつだよ：https://rentry.org/nyznvoy5
YouTubeのリンクをAI Studioに貼り付けて，再現したいならこのプロンプトをあげたんだ：
このトークを記事形式に再フォーマットして．えー／あーは削除して，ただし要約はしないで，内容は実質的に同じになるように．可能ならスライドの内容も含めて．

なかなか良いね．ただBismarckじゃなくてFontaneだよ． 😉 あと，俺は転記されてるやつじゃなくてCGP Greyと比較してるんだ． 😄

トークの一部，https://www.amundsens-maxim.com/ を思い出したよ．

あのトークを作業してる時にこれ見たかったな！リソースに追加しとくわ！

1ヶ月前に逆の問題あったんだよね。既存データもドメインモデルもAPIもないGreenfieldプロジェクトで。APIとか永続化レイヤーをドメインモデルと違うようにモデリングする理由なかったから、同じクラスを3回実装して、その上にマッピングを2つ乗っけたんだ。何のために？
まあ、いつかAPIコンシューマーとか既存データができて、その時のシステムを変えなきゃいけなくなるからさ。

面白いね。たぶん、モダンな便利さが結合を促してるのかも。だからシングルモニターとかLSP使わない達人がたくさんいるのも納得だよ。