同一性が必要になるObject

同一性を区別する

複数のObjectにおいて区別が必要なのかどうかを重視するため、Entityのような概念が重要になる

例えば人間というObjectは同姓同名であっても別の人同士は区別されないといけない

逆に「氏名」というObjectは重複している場合には区別の必要はない

ライフサイクルを通して一意性の区別がつかないといけない

持っている属性が異なる状態になったとしても一意性の区別がつかないといけない

そのObjectの持つ属性や振る舞いが同じかどうかは関係ない

属性が異なっていても、同じ概念であることもあるし、

属性が一致していても、別概念であることもある

余談だがプログラミングにおける参照の一致も今の話とは関係ない

== が不一致でも同じ概念を指すこともある

寧ろ、参照以外の方法で同一概念であることを表すモノが必要になる(後述)

何がEntityになるかは扱うDomain Modelによって異なる

だからEntityの線引きの難しさが存在する

ここもかなり重要

同一プロダクト内でも、扱うドメインモデルの差異によってEntityになったりそうでなかったりする

同一性を定義する

「同一のものである」とは何を意味するか、を定義する

複数の値を使う例

テーブルのセルを組 (ln, col) で区別するなど

「userの氏名」などは一意ではない

扱うドメインモデルによって異なるが一般的には一意ではないだろう

同姓同名でも異なる人間は異なる人間である

何れにせよ、それらが異なるモノ同士は絶対に異なる概念である、ようにしないといけない

平たく言えばidは、そのシステム内でユニークでなければならない

当たり前だが

逆に言えば、Entityなobject同士を比較する際に、その判断の為の属性(e.g. id )以外の属性が必要になったらおかしい

その属性(e.g. id )のみで判断できるべきである

設計時に気をかけるところ

一つ一つのEntityはできるだけ薄く作る

同一性に集中できるようにする

その同一性区別が必要になる概念にとって必須な振る舞いと、その振る舞いが必要とする属性のみを持たす

「今から更に追加しようとしているその振る舞いは、別のEntityとして定義できないか」を常に考える

各Objectに対して結果が一意となることが保証される操作を定義すること

外部から同一性のチェックが可能である必要がある

異なるobjectが同一Entityを表しているかどうかを判断できる必要がある

「 User.id を比較する」など

p.90について

「同一のobjectが、同じclassから生成されるとは限らない」とあるが、わかるようでわからない

どういう状況のことを言っているのかいまいちわからない

class == objectという構図がそもそもおかしい、という話になってくるということか？

参考

『エリック・エヴァンスのドメイン駆動設計』 5章

ブログ記事とかをサーフィンする前に、まずこれを読んどけばよかったと思った

具体例も豊富でイメージしやすい