2012-10-09 3 views
1

가능한 중복 :
Value vs Entity objects (Domain Driven Design)DDD 값 오브젝트

ValueObject는 다음과 같이 정의

값을 가지는 도메인 주도 설계 (DDD)에서

Object는 일부 특성 또는 특성을 설명하지만 identi의 개념을 갖고 있지 않은 개체입니다. 네.

'클라이언트'엔티티와 '주문'엔티티가 있다고 가정 해 보겠습니다. 주문은 클라이언트와 관련이 있으므로 일반적으로 클라이언트 엔터티 자체를 참조하지 않을 수 있으므로 Order 클래스에 ClientId 필드를 추가합니다. 지금까지 그렇게 좋은 ...

이제 클라이언트의 이름, 클라이언트 상태, 을 포함 할 값 개체 ClientInfo를 만들 수 있을지 궁금합니다. ClientId? ClientInfo는 clientName, clientStatus 및 clientId에 대한 getter만으로 변경할 수 없습니다.

엔티티 식별자가있는 값 개체가 있습니다. 이것은 가치 객체의 정의에 대한 것입니까, 아니면 여기 안전합니까?

+0

이 질문은 언급 된 질문과 중복되는 것으로 생각하지 않습니다. 여기서 OP는 값 개체 내의 ID를 구체적으로 묻는 것이지 엔티티/값 개체의 일반적인 개념이 아니라 ID에 대해 특별히 묻습니다. – theDmi

+0

실제로 이것은 참조 된 질문과 중복되는 것이 아니라 더 구체적으로 값 개체와 그 제약 조건을 대상으로합니다. 정의는 신원 개념이없는 ValueObject에 대해 이야기합니다. 즉, ValueObject가 ValueObject를 나타내는 ID를 가져서는 안됩니다. 그러나 ValueObject는 엔티티 – ChrisMir

답변

3

엔티티 식별자를 참조하는 값 객체가 좋습니다. 동일한 정보가있는 두 개의 ClientInfo 객체가있는 경우 완전히 상호 교환 할 수 있습니다. 문자열이나 정수와 같은 값입니다.

+1

을 참조하는 식별자를 포함 할 수 있지만 값 객체는 아닙니다 – NimChimpsky

+0

값 개체입니다! 자체 ID는 없으며 엔티티의 ID를 나타내는 값을 포함합니다. –

+0

ID를 나타내는 값은 여전히 ​​ID이며, 고유하게 클라이언트에 연결되어 있으며 값을 나타내는 것이 아닙니다. – NimChimpsky