Entity
(構成要素が変化しても) 固有のアイデンティティを持つオブジェクトのこと
計算を超えても同一性を担保したいのでアイデンティティを持たせる
雑に言えば、固有のIDなどを持つオブジェクトのこと
同一性を区別する
複数のObjectにおいて区別が必要なのかどうかを重視するため、Entityのような概念が重要になる
例えば人間というObjectは同姓同名であっても別の人同士は区別されないといけない
逆に「氏名」というObjectは重複している場合には区別の必要はない
ライフサイクルを通して一意性の区別がつかないといけない
例えば、「注文」は、検証されたり、配送用だったりで構成要素が変わるが、OrderIDは不変である
持っている属性が異なる状態になったとしても一意性の区別がつかないといけない
そのObjectの持つ属性や振る舞いが同じかどうかは関係ない
属性が異なっていても、同じ概念であることもあるし、
属性が一致していても、別概念であることもある
余談だがプログラミングにおける参照の一致も今の話とは関係ない
==が不一致でも同じ概念を指すこともある
寧ろ、参照以外の方法で同一概念であることを表すモノが必要になる(後述)
同一性を定義する
「同一のものである」とは何を意味するか、を定義する
複数の値を使う例
テーブルのセルを組(ln, col)で区別するなど
「userの氏名」などは一意ではない
扱うドメインモデルによって異なるが一般的には一意ではないだろうmrsekut.icon
同姓同名でも異なる人間は異なる人間である
何れにせよ、それらが異なるモノ同士は絶対に異なる概念である、ようにしないといけない
平たく言えばidは、そのシステム内でユニークでなければならない
逆に言えば、Entityなobject同士を比較する際に、その判断の為の属性(e.g. id)以外の属性が必要になったらおかしい
その属性(e.g. id)のみで判断できるべきである
設計時に気をかけるところ
一つ一つのEntityはできるだけ薄く作る
同一性に集中できるようにする
その同一性区別が必要になる概念にとって必須な振る舞いと、その振る舞いが必要とする属性のみを持たす
「今から更に追加しようとしているその振る舞いは、別のEntityとして定義できないか」を常に考える
各Objectに対して結果が一意となることが保証される操作を定義すること
外部から同一性のチェックが可能である必要がある
異なるobjectが同一Entityを表しているかどうかを判断できる必要がある
「User.idを比較する」など
参考
ブログ記事とかをサーフィンする前に、まずこれを読んどけばよかったと思ったmrsekut.icon
具体例も豊富でイメージしやすい