書籍の感想です。
読んだ記事
『イミュータブルデータモデルで始める実践データモデリング』
掲載：WEB+DB PRESS Vol.130 特集１
著者：川島義隆
感想
概念と実装を区別する
ER図を書く/書かれていることは多いですが、ほぼ物理レベルになっています。物理レベルになると技術的な都合がいろいろと入ってきてしまい、本来求められる形が見えにくくなってしまいます。なのでできる限りWhyとして論理レベルも残しておくのが良いと思っています。
（とはいえ物理レベルで考えがちなので、うまく実装を切り離して論理レベルを考えるようにしたいところ）
２つの複雑さ
ソフトウェアでも、小さな１つのクラスにカプセル化するのは「単一のエンティティに内包される複雑さ」を解決するため、と考えられます。一方これに難色を示してトランザクションスクリプトにするのは「エンティティの数の多さからくる複雑さ」を気にしてのことだと思います。複雑さを議論する場合はどちらの複雑さについての話なのか認識を合わせたほうが良さそうです。
また、この「２つの複雑さ」は「モノリスと分散システム（マイクロサービス）」にも当てはまりそうです。マイクロサービスにしても生来的複雑さは変わらないので、それをコントロールする力はどうしても必要になるでしょう。
変更日時
とりあえずで付けがちな「変更日時」ですが、自身の経験からも実際に役に立ったことはありません。
データベースに履歴を残すほどでなければ、アプリケーションログにでも出力したほうがまだ有用な情報を残せると思います。
マスタ/トランザクションとリソース/イベント
テーブルの接頭辞に「M_」や「T_」を付けたプロダクトに関わったことがありますが、これらの分類について明確な基準は示されていませんでしたし、実装上も接頭辞以外の違いは見て取れませんでした。なので、結局これらを元に何かの判断をしたことはありませんでした。
曖昧なマスタ/トランザクションといった分類よりも、リソース/イベントに注目した方がどのように扱うべきなのか分かりやすいと思います。
やってみた
掲載されていたモデルについて、単一エンティティと分割されたエンティティそれぞれで実装してみました。
残念ながらがこのくらいの規模ではそれほど複雑にはならないものの、単一エンティティの方では更新するカラムを間違えてしまうことがありました。。一方で分割されたエンティティの方はイベントごとにテーブルが分かれるのでそうした間違いはありませんでしたが、テーブルをJOINすることが多いので、テーブルが多くなるとこのあたりが課題になりそうです。
今回はやれませんでしたがイベントソーシングパターンも関心があるので今後の課題とします。
まとめ
イミュータブルなデータベース設計については『現場で役立つシステム設計の原則』でも解説されていますが、こちらは物理レベルが中心です。それ対してこちらの記事は論理レベルが中心で、モデリングを通してコミュニケーションしたり分析したりするための方法について学ぶことができました。
また複雑さについてうまく説明できないモヤモヤした部分があったので、「２つの複雑さ」という見方がその解決になりそうです。