※ chatgpt-5.4にずっと思ってた事書いてもらいました
「それ、DDDじゃないですか？」 「いや、これはクリーンアーキテクチャ寄りですね」 「RESTっぽくはあるけど、厳密にはRESTじゃないかな」 「まあでも実質マイクロサービスですよ」 「この実装、関数型っぽくてよい」 「CQRSをやるほどではないけど、CQSではある」 「疎結合にしたい」
ITエンジニア、会話の7割くらいこれでできていないか？
私はできている気がする。
いや、正確に言うと、できてしまっている。
そしてこれは別に、業界全体が雑だとか、みんな言葉の意味を知らずに喋っているとか、そういう単純な話ではない。 むしろ逆で、ちゃんと勉強している人ほど薄々わかっているはずだ。
プログラミング用語、思ったより厳密じゃない。
「厳密な定義がある用語」と「現場で育った用語」は別物
たとえば「二分探索」とか「トポロジカルソート」とか「O(n log n)」とかは、かなり意味がはっきりしている。
ここにはあまり解釈の余地がない。
二分探索は二分探索だし、DFSはDFSだし、外部キーは外部キーだ。 もちろん文脈による揺れは多少あるけれど、少なくとも「人によってだいたい違うものを指している」という事態にはなりにくい。
一方で、現場でよく出る言葉は違う。
- オブジェクト指向
- 関数型
- REST
- マイクロサービス
- クリーンアーキテクチャ
- 疎結合
- DDD
- CQRS
- モジュール性
- スケーラブル
- リアクティブ
- フレームワーク
- ライブラリ
このへん、全員がなんとなく雰囲気を共有しているけれど、いざ定義を詰めると急に足元がぬかるむ。
みんな言ってることは違うのに、なぜ会話が成立するのか
ここが面白いところで、成立してしまうのである。
たとえば「これはマイクロサービスではない」という人と、「いや十分マイクロサービスだろ」という人がいたとして、両者の言っていることをよく聞くと、別に片方が完全に間違っているわけではない。
片方はこういう意味で言っている。
- サービス単位でデプロイされている
- チームごとに責任境界が分かれている
- 個別にスケールできる
もう片方はこういう意味で言っている。
- DBを共有している
- デプロイは分かれていても境界が弱い
- 実質的には分割モノリスでは？
どちらもわかる。
そして、現場ではこの「どちらもわかる」が頻発する。
つまり我々は、厳密な単語の定義を共有しているというより、その単語の周辺にある問題意識とか思想とか、典型的な形を共有している。
だから会話が成立する。
でも成立しているだけで、厳密とは限らない。
「CQS」と「CQRS」の話をすると全てがわかる
最近この手の話でわかりやすいなと思ったのが CQS と CQRS である。
CQS は Command Query Separation。 ざっくり言えば「状態を変える処理と、値を返す処理を分けよう」という原則。
CQRS は Command Query Responsibility Segregation。 ざっくり言えば「読み取り責務と書き込み責務を、モデルや責務として分けよう」という設計。
さて、ここで問題です。
Service を command 系と query 系で分けたら、それは CQRS ですか？
私はもうこの時点で少し笑ってしまう。
なぜなら、この問いに対してエンジニアが3人いたら、だいたい4つくらいの答えが返ってくるからだ。
ある人は言う。
それはまだただの CQS で、CQRS ではない
別の人は言う。
アプリケーションレイヤで責務を分けた時点で、軽い CQRS と呼んでいい
さらに別の人は言う。
read model と write model が別になって、非同期で同期されて初めて CQRS だ
全部わかる。
全部わかるのだが、全部違う。
これが何を意味するかというと、CQS と CQRS の間には広大なグラデーションがあるということである。
我々はたぶん、そのグラデーションに向かって「だいたいCQRS」みたいな顔をしている。
「RESTful」はだいたい褒め言葉
REST もそうだ。
厳密な REST は、かなり制約が強い。 でも現場で「REST API」と言ったとき、多くの場合それは
- HTTPで
- JSONを返して
- URLがリソースっぽくて
- GET/POST/PUT/DELETEをそれっぽく使っている
くらいの意味で使われている。
つまり「RESTful」は実質的に、
なんかちゃんとしてそう
という褒め言葉として使われている瞬間がある。
もちろん本当に REST を厳密に考えている人もいる。 でも日常会話においては、「GraphQLじゃない、gRPCでもない、RPCっぽすぎないHTTP API」くらいの感じで運用されていることがある。
それでも会話は成立する。
成立してしまう。
「関数型っぽい」は、たぶん全員違うものを見ている
「このコード、関数型っぽいですね」
これも危険な発言である。
この一言で人が見ているポイントはバラバラだ。
- 純粋関数が多い
- mutable state を避けている
- map / filter / reduce を使っている
- クラスより関数中心
- 副作用を外に追い出している
- monad がいる
- for 文が少ない
全員、違うものを見て「関数型っぽい」と言っている可能性がある。
にもかかわらず、会話はなんとなく前に進む。
なぜか。
みんなが厳密な定義ではなく、その言葉が帯びている美意識を共有しているからである。
たぶん「設計用語」はほぼ全部そう
ここまで書いていて思うのだが、特に危ないのは設計用語である。
アルゴリズム用語は比較的安定している。 言語仕様の用語もかなり安定している。 DB理論や型理論も、ちゃんとやると厳密だ。
でも設計の言葉は、急に空気が混ざる。
- 疎結合
- 拡張しやすい
- 保守しやすい
- きれい
- 責務が分離されている
- DDDっぽい
- クリーン
- スケーラブル
- モジュール性が高い
このへん、全部ちょっと危ない。
危ないというのは、「嘘だ」という意味ではない。 わかった気になれるのが危ないのである。
「この設計は疎結合です」と言われたとき、本当に知りたいのはそこではない。
知りたいのはたぶんこういうことだ。
- 依存方向は一方向なのか
- 実装詳細に直接依存していないのか
- 差し替え可能なのか
- 変更の波及範囲が小さいのか
- デプロイ単位まで分離されているのか
でも会話の中では、それら全部を「疎結合」の一言で済ませてしまう。
ではプログラミング用語は全部ダメなのか
そんなことはない。
むしろ逆で、こういう曖昧な言葉は便利だから広まっている。
毎回、
「読み取りはDTOで最適化していて、書き込みは集約経由で行い、一部の参照モデルは非同期投影です」
などとフルで説明していたら日が暮れる。
だから「軽いCQRSです」と言いたくなる。
これは省略記法としては優秀だ。
問題は、その省略記法を定義そのものだと思い込む瞬間である。
「これはCQRSです」 「いや、それはCQRSではありません」
この会話、不毛なことがある。
なぜなら多くの場合、本当に重要なのはラベルではなくて、
- 何を分けているのか
- どこが同期で、どこが非同期か
- どんな制約があるのか
- 何を得て、何を失うのか
だからだ。
エンジニアは定義で戦いがち
インターネットを見ていると、エンジニアはよく定義で戦っている。
「それは本当のDIではない」 「いや、それはフレームワークではなくライブラリ」 「そのコードは関数型ではない」 「それはマイクロサービスではない」 「RESTを名乗るな」 「DDD警察だ」
気持ちはわかる。
定義を大事にすること自体は悪くない。 むしろ大事だ。 厳密さが必要な場面はたくさんある。
でも、設計やアーキテクチャの会話では、定義が固定されていないことが多い。 そのときに「用語の純度」で殴り合うと、話が進まない。
ここで必要なのは、たぶん厳密な単語を1個投げることではなくて、その単語を展開して説明することなのだと思う。
「疎結合です」ではなく、 「インターフェース越しにしか参照せず、ドメイン層はインフラ実装を知らないです」と言う。
「マイクロサービスです」ではなく、 「デプロイは別ですがDBは一部共有です」と言う。
「RESTです」ではなく、 「HTTP+JSONのCRUD APIで、HATEOASはやっていません」と言う。
このほうが100倍伝わる。
でも俺たちは、これからも雰囲気で用語を使う
ここまで読んで「じゃあ今後は全部厳密に言おう」と思った人がいるかもしれない。
たぶん無理である。
我々はこれからも言う。
「DDDっぽくやりたい」 「ここは関数型で」 「ちょっとCQRS寄りにしたい」 「RESTっぽく整えよう」 「モジュラモノリスがいい」 「疎結合にしよう」
そして相手もだいたいわかる。
わかるから使う。
たぶん大事なのは、自分たちが雰囲気で使っていると自覚することだ。
自覚していれば、「この言葉、人によってズレるかもな」と一歩立ち止まれる。 自覚していれば、定義の殴り合いではなく具体の話に戻れる。 自覚していれば、「それってどういう意味で言ってます？」と聞ける。
雰囲気で使うこと自体が悪いのではない。 雰囲気を定義だと思い込むことが危ないのだ。
結論
俺たちは雰囲気でプログラミング用語を使っている。
でもそれは、別に不誠実だからでも、勉強不足だからでもない。
技術の世界には、
- 形式的に定義しやすい言葉
- 実務の中でグラデーションを持つ言葉
- 思想や美意識を運ぶ言葉
が混ざっている。
だから、用語は便利な圧縮でもあり、誤解の温床でもある。
たぶん必要なのは「用語を捨てること」ではなくて、用語の解像度を必要に応じて上げられることなのだと思う。
「これはCQRSです」で終わらせない。 「それ、どのレベルですか？」と聞ける。 「疎結合です」で終わらせない。 「依存方向はどうなってます？」と聞ける。
そのくらいがちょうどいい。
我々は雰囲気で用語を使う。 そして、ときどき正気に戻って具体の話をする。
たぶん、それでいい。
追記
この記事もたぶん、厳密には「雰囲気で書かれた技術記事」です。
