シンプルは作れる！イミュータブルデータモデルの真髄

JJUG CCC 2025 Spring で話したものです。

昨今の生成AIによって、偶有的な難しさは激減した。し、これからも減り続けることだろう。

だが、本質的な難しさ(複雑さ)が変わるわけではない。

「本質的な複雑さ」とは何か？ 本質的な複雑さにはどうアプローチすれば良い?

本質的な複雑さはどう設計しても変わらない。

すなわち本質的複雑さは保存法則がある。

だが、本質的複雑さはその度合いに応じてComplexとComplicatedの複雑さがある。Complexな状態では、本質的複雑さがどれだけ含まれているかが把握できないことがある。動かしてみないと分からない、動かしてみても分からないことも…

したがって、データモデリングを通じて「時間と労力さえかければ理解可能」な状態にしておくことが重要。

Complicatedな状態に持っていくために、イミュータブルデータモデルでモデリングすると良い。

イミュータブルデータモデルの詳細は、こちら

このようなComplexのサインを見逃さず、データモデリングしよう。

FAQ

Q1. イミュータブルデータモデルはテーブル設計の指針なの?

No

あくまでも実装のことは一旦おいておき、要求の本質的な複雑さをデータモデリングを通じて明らかにすることが狙いです。

とはいえ、せっかくSimpleなエンティティを見出したのに、それらをまた混ぜこぜにして、1つのテーブルとして実装する意義は薄い(特にイベントエンティティ)。

なので、テーブル設計の指針とも言えなくもない(特にイベントエンティティ)

Q2. UPDATEを一切やらずにシステムは作れるのか?

「イベントエンティティに対して更新はしない」なので、通常は…

イベントエンティティは原則UPDATEしないように作ります。

リソースエンティティは通常UPDATEするように作ります。

Q3. クエリが大変になるのでは?

多数のテーブルに実装されるのは主にイベントエンティティ。

イベントエンティティについて複雑なクエリになるのは、ロングタームイベントパターンみたいなもの。

これは偶有的複雑さ(イベントの進行状態を表すエンティティ)を導入し、現実的な速度でSQLが実行できるように実装するのがおすすめ。

Q4. テーブル数が増えるので理解が困難になるのでは?

本質的複雑さは、どう実装しようが変わらない。少ないテーブル数の方が「分かりやすい」と感じるのであれば、要求の複雑さを過小にとらえているサイン。

多数のテーブルに実装されるのはイベントエンティティ。

イベントエンティティは、Bounded Contextに分割しやすいので、適切な分割統治すれば一度に把握すべきものは多くない。

実装にあたって、Complexな状態(いくつかの論理エンティティをまとめて1つのテーブルで実装する)にするのももちろんナシではないが、振る舞いの方にその皺寄せがいくことを忘れてはならない。

Q5. 実際どこまでイベントを作るべきか?

全部が全部必要ではない。記録・保管にも金がかかる。

イベントがお金を産む

イベントの記録がないとお金を失うリスクがある

ような性質のものを優先的に考えるようにしよう。

Q6. イベントのデータ量がめちゃ増えてコスト嵩むのでは?

まずQ5の回答の通り、お金を産む・失うリスクがあるもの以外を記録しないようにしよう。

それから、これはどう設計してもトラフィックの多いイベントを記録していくと、データ量が膨大になるが、これは定期的にパージ(またはアーカイブ)するより他にない。

この時、イベントがComplexなエンティティになっていると、複数の業務調整が必要になるためパージの要件がまとまりにくい。Complicatedな状態にしておけば、パージの設計も比較的容易になるはずだ。