第4章：スキーマ進化は“文化”だ──壊れにくさのための折り合い設計
第4章：スキーマ進化は“文化”だ──壊れにくさのための折り合い設計
『データ指向アプリケーションデザイン（DDIA）』第4章の読書メモです
「スキーマってなに？」「シリアライズってよく聞くけど…」という疑問から、設計文化の話へとつながっていく章でした
エンコーディングとスキーマ、ややこしいけど避けて通れない
この章に出てくる話は、「API仕様」や「DBの互換性」を考えるときに避けて通れない
でも用語だけ見ると、どれもバズワード感があってピンとこない
「とりあえずJSONでいいっしょ？」は本当にいいのか？
たとえばよくあるこの流れ：
「シリアライズ？それってなんだっけ。JSONでよくない？」
実はその「よくない」が、この章の中心テーマ
JSONは確かに楽だけど、たとえば金融系では「整数と浮動小数点の区別が曖昧」なだけでNGになる世界もある
スキーマって“自己紹介”みたいなもの
スキーマはつまり：
「私はこういうつもりでこのデータ扱ってます」
という“自己紹介”
たとえば：
{ "金": "100万" }
って書かれていても、それが「キャベツ100万」なのか「給与100万」なのかは文脈次第
この「文脈＝意味の前提」をどう伝えるか？が、DDDの境界づけられたコンテキストやユビキタス言語にもつながってくる
スキーマ進化、地味に破壊的
- 任意パラメータの追加 → OK（古いクライアントが無視できる）
- 既存項目の削除・意味変更 → NG（クライアントが壊れる）
理屈はわかってても、実装で守るのは難しい
特にDBとAPIの型が密結合してると、変更コストが高騰する
「どうせ誰も見てないし」ってフィールド名変えると、わりと死ぬ
図4: スキーマ互換性のパス（Backward / Forward / Incompatible）
AvroとかProtocol Buffersとか、何が違うの？
- スキーマを定義できる
- 高速なエンコード／デコード
- サイズが小さい
より重要なのは 「ルールが固定されている」 こと
ルールがあるから：
- 書き手と読み手の齟齬が起きにくい
- 進化時のバージョン管理がしやすい
- 多言語でも読み書き可能
結局「機械にも文化が必要」って話
ハッシュバン（#!/bin/bash）とスキーマは似ている
これは自分の気づきだけど：
#!/bin/bash
って書くのも、「これはbash用スクリプトですよ」って宣言してる
スキーマも同じで、「誰がどう読むかを先に決める仕組み」
マイクロサービス＝プロトコル地獄？
この章、さりげなくマイクロサービスの話も出てくる
REST、gRPC、メッセージパッシング、イベント駆動…
どれも疎結合を保つ工夫だけど、裏を返せば「結合の作法を決めないといけない」話でもある
gRPCのようなストリーム通信も、どこまで状態を保持するかが曖昧だと崩壊しやすい
非同期処理、便利だけど魔物
メッセージパッシング＝非同期処理
これはもう常識みたいになってるけど、**「非同期にしただけで全部解決した感」**は危険
- イベント発行しても、誰がいつ処理するかは保証できない
- 再処理・エラーハンドリングがどこかに必要
- それは結局アプリ側の責任になる
非同期は万能薬じゃなく、トレードオフの一手段
バッファと疎結合はテスト性にも効く
中間層やメッセージングが持つ「バッファとしての役割」は、信頼性だけじゃなくテスト容易性にもつながる
依存注入（DI）でテストしやすくなるのと同じで、疎結合は構造の安定性に効く
アクターモデル、実はSmalltalkの延長戦？
アクターフレームワークも登場
分散環境向けの構造だけど、基本はSmalltalk的OOPの延長に見える
- 各オブジェクトが自己完結して、メッセージでやりとりする
- 並列処理に強い思想
- 分散環境にOOPが適応した形とも言える
ここまでくると、「ソフトウェアの発想って全部どこかでつながってるな」と思わされる
✍️ まとめ：スキーマやプロトコルは“人と人の会話の延長”
構文、構造、進化、互換性…
どれも難しく見えるけど、結局は「壊れにくい会話」をするための文化設計
- ちゃんと名乗る（スキーマ）
- お作法に従う（プロトコル）
- 変わるときは事前に伝える（バージョニング）
これらを設計に落とし込むのは、技術選定ではなく 運用設計や文化設計 の領域
設計はやっぱり奥深いのかもしれない
💡 設計Tips
- スキーマ進化は「技術選定」だけでなく「文化の取り決め」でもある
- 任意項目の追加は比較的安全、意味の変更や削除は壊れやすいことを前提に
- 「とりあえずJSON」は便利だが、意味の曖昧さは設計の負債になりうる
- プロトコルの選定（REST, gRPC, メッセージ駆動）は、疎結合だけでなく「変更コスト」の見積もりとセットで考える
- 非同期処理は万能ではなく、どこで確実性を担保するかを設計時に意識しておくとよい
Discussion