データモデルにおいて、IDとはなんなのか

この観点はまず把握しておくと良い

エンティティというものにIDが必要である

私は、名前が変わっても住所が変わっても私であり、変わらない

すなわち、「私」のあらゆる属性は、「私」の一意性を示さない

私は変わらないが、その属性が変化したと考える

時間経過、属性変化がおきても「変わらないもの」がある

哲学的には、何を持って「私」あるいは「同じ存在」とするのかは難しい

実生活では、そこまで深く考えない

同一性が何によって定義されるかは難しいが、我々は「同じ」を直感して知っている

その直感は共通認識としてある

これをシステム上で扱えるようにするためには、どの既存の属性とも違う属性として、idが必要

数字や文字列を割り振る必要がある

データの構造上としては属性と似ているが、意味が違う

code:json

{

id: 123,

name: "miyamonz"

}

nameが変わったら、ある存在(idが123)の名前が変わった、と読める

異なる存在(id=456)が、同じ名前miyamonzを持ってる、

という情報と解釈できる

value objectにはidは不要だろう

100円と100円は、同じで、それを区別する必要がない

同じような概念でも、システムやその前提に応じて、エンティティとすべきかどうかは変わる

たとえば、硬貨を管理するシステム（珍しい硬貨を保管するとか？）なら、100円玉にidを振る必要があるかも

硬貨ひとつひとつにidを振り、何円玉で何年製で、状態はどうか、価格をつけたり…

以上の話は、「"エンティティ"というものにIDが必要であること」の説明であった

しかし、IDがあるからといって、それがエンティティとは限らない

単なる識別コードのような使い方の可能性もある

idは”なにか”を識別(identify)するためのもの(identifier)である

その対象は、エンティティであったり、そうでなかったりするだろう

value objectにidを付与しても、矛盾が起きないように定めれば、システムは動くはずだ

同一のvalue objectに同じidが得られるようにするとか

その際のidは、idというよりkeyだろう

RDBにおいて、primary keyとして使われるidは、上の意味でのidなのか、そうでないのかは気をつける必要がある

欲を言えば、異なる意味の方にidという単語は使わないほうが良いのかも知れない

keyとか？

エンティティに対して、タイムスタンプをキーにその状態の値を保存することを考える

そのとき、個別の状態の値はvalue objectとみなせる

エンティティは状態であるが、状態のスナップショットは事実である

事実は値である。value objectだ

そう考えると、entityとvalue objectの違いを意識することで、モデリングの手がかりとする行為は、

言い方を変えれば、ただ単にデータのライフサイクルの有無を考えているのと同じに過ぎないのでは