イミュータブルデータモデル #1
はじめに
WEB+DB PRESS Vol.130の実践データモデリングの特集を順次１章ごとにまとめていきたいと思っている。#1から始まり、＃５までのシリーズにしていきたい。＃１〜５のまとめもしたいと思っている。
第１章「良いデータモデルの条件」の要点、学びをメモがてら文章に落とす。
良いデータモデルとは
データを永続化する/しないに関わらずデータをモデリング（抽象化）によって、対象の複雑さを認識し、対処する。良いデータモデルとは、成果物とそれを生む過程の中で考慮漏れなどの発見につながるもの。
-> 正しくモデルを作ることは前提重要であるが、プロセスも重要
モデリングについて
エンジニアのためのモデリングではなく、プロジェクトに関わる人全ての人が理解できる共通認識としてのモデリングが必要。抽象化の際には、何を同じとみなすか、何を違うとみなすかが重要で、それを認識できる形に落としたものがモデル。
エンティティ
エンティティは、任意の１つのものを識別するためのIDが存在し、IDに関数従属する属性で構成されるものを指す。ある”１つのもの”を考えようとした時に、状況や要求に応じてその境界が曖昧になることがしばしばある。そのため、何をどうやって区別するかという決め事が必要になる。決め事をする際の観点が以下の３つ。
- 単一性
- 同一性
- カテゴリ
上記３点をざっくりまとめると、「何をもって１つと識別し、何をもって同じとみなして意味を持たせるか」が決まっていれば適切にエンティティを抽出することができる。ここでのルール定め、全体で認識を揃えておかなければならない。
問題と解決
対象としているドメインに存在する問題を認識する際のモデリングと、対象ドメインの問題をシステムで解決する際のモデリングがあり、問題の中にはシステムを利用しなくても良い場合があることを念頭に思考する必要がある。
要求の掘り起こし
データの変更イベントに対する意図/理由の抽出は重要である。単に変更するのではなく、”何のために、どんな変更”をするのかによってデータの変更の意味が変わる可能性があり、変更の意味ごとにエンティティを分けるというようなデータモデリングも考えられる。単に変更であれば１つのエンティティに変更時刻などの属性を持たせるだけですむが、変更に種別があり、「本人によるユーザー情報の変更」、「規約違反による運営側がユーザーを退会させる」では意味が違う。この種別が増えてくると前述の複雑さが増すため、その意図を正しく認識できると複雑さなものを抽象化し簡単な理解しやすいものにできる。本の中でも例に出ていたが、地図などがいい例だなと思った。余計な複雑さを取っ払い建物の位置関係、方角のみに焦点を当てることで人間が認識しやすくなっている。
まとめ
対象ドメインの抽象化とそのプロセス＝良いデータモデルによって、みんなで複雑さに立ち向かっていく。そんな姿勢が必要だと理解した。
早く２章読んで、まとめよう。
Discussion