ドメイン主導の設計では、タイムスタンプはプロパティまたは値オブジェクトですか？
私には、作成された瞬間を記録する必要があるいくつかのエンティティといくつかの値オブジェクトがあります。ここで、値オブジェクトは独自のルールセットを持つプロパティのコレクションであり、同じプロパティを持つ2つの値オブジェクトは区別できないことを読みました。
今、私はおそらくこれに標準のC＃のDateTimeデータ型を使用するつもりですが、内部的にどのように実装されているのか本当にわかりません（プリミティブとしてのプロパティであるはずのUnixタイムスタンプである可能性がありますが、複数のプロパティが相互に関係している2038年問題の解決策がある場合は、さらに複雑になります）。
違いは、タイムスタンプには独自のルールセットがある（たとえば、「1月35日」は有効な日付ではない）が、それらのルールを適用しないことです。言語自体がします。日付は常に内部で作成されます。ユーザーが送信したものを日付に解析することはありません。
したがって、私はタイムスタンプがプロパティであることに傾いています。しかし、私は考え始めました：そのルールをアプリケーションの外部で定義されているanyデータ型に適用できますか？たとえば、画像ファイル。 JPEG仕様に従って正しく構造化することは担当していません。言語はそれを行います。ファイルサイズに制限を設けることもできますが、同様にエンティティがその文字列の長さを制限することもあり、その理由で値オブジェクトに変更されることはありませんが、間違っている可能性があります。
そして、もしデータ型のためのルールのオーダーメイドのセットがあったらどうなるでしょう。私が協力している会社がすでに他の場所に実装されており、ライブラリとしてインポートしているという請求書。これは、データ型が複雑になる可能性があります。
したがって、首尾一貫して：
- タイムスタンプは値オブジェクトですか、それとも1つのプロパティですか？
- 値オブジェクトとプロパティの違いは何ですか？ローカルで定義されたルールのセットですか、それとも別のものですか？
さらに具体的には、私はこれら2つのモデルのどちらかを選択しています（多かれ少なかれ、実際のコードに直接対応していると理解しています）。
バージョン1：
バージョン2：
値オブジェクトは、IDはありませんが、その値によって完全に定義されるオブジェクトです。タイムスタンプはその説明に完全に適合し、整数と文字列にも適合します。
同時に、タイムスタンプはより大きなオブジェクトのプロパティにもなります。値オブジェクトも属性であることが非常に普通であるため、値オブジェクトまたは属性のどちらを選択するかは問題ではありません。
UMLダイアグラムでどのように描画するかは、表示する情報に完全に依存します。経験則として、値オブジェクトの内部構造がダイアグラムの対象者に関連している場合にのみ、バージョン2で行ったように、独自の（ステレオタイプ化された）クラスボックスでのみ値オブジェクトを描画します。それ以外の場合は、属性として表示するか、属性の存在が図の対象者に関係ない場合は完全に省略します。
タイムスタンプは値オブジェクトです。IDはなく、値コンポーネントによってのみ定義されます。
あなたのケースでは、組み込み型を使用するか、独自の値型（C＃構造体など）を使用できます。
値オブジェクトは、より大きなオブジェクトのプロパティにすることができます。特にそれが値型の場合（言語が値型をサポートしない場合、微妙な違いが生じる可能性がありますが、C＃の場合はそうではありません）。
したがって、両方の肯定は相互に排他的ではなく、値とプロパティではなく、組み込み型とカスタム型のどちらが重要です。
タイムスタンプは値オブジェクトですか、それとも1つのプロパティですか？
これはあなた次第です。両方にすることもできます。値オブジェクトは、他の値オブジェクトで構成できます。
ただし、明確にするために、プリミティブに有用な名前を付けても、値オブジェクトにはなりません。
class ActiveState
int timestamp <== A property that is not a value object (not an object at all)
class ActiveState (Value object)
Timestamp t <== A value object that's a property on the value object, ActiveState
class Timestamp (Value object)
int ts (property)
上記のすべてのクラスはValueオブジェクトです。どちらを取得してもかまいませんが、同じように使用できます。
ただし、ここでの実際の混乱にはValue Objects vs Entitiesが関係していると思います
Eric Evansによるドメイン駆動設計、ページ99から：
モデルの要素の属性のみを気にする場合は、VALUE OBJECTとして分類します。伝達する属性の意味を表現し、関連する機能を提供します。 VALUE OBJECTを不変として扱います。 IDを指定せず、ENTITIESを維持するために必要な設計の複雑さを回避してください。
ActiveStateで "Id"をたたいた2番目の値は、値オブジェクトではありません。それはエンティティです。
何かがエンティティまたは値オブジェクトであるかどうかは、それがどのように使用されているかに依存します。たとえば、あなたの車のタイヤはおそらく価値のあるオブジェクトです（どのオブジェクトを取得するかは気にしません）。ただし、タイヤのパフォーマンスを個別に追跡している研究チームは、どれがどれであるかを気にするでしょう。そのため、各タイヤには、追跡できる一意のIDが必要であり、それによってエンティティになります。