개체/값 개체 선택

Question

도메인 기반 디자인에서는 ID가있는 개체가 엔터티라는 것이 일반적입니다. 예를 들어 어떤 사람이라도 여러 가지 형태의 신원 (이름 등)을 갖게됩니다.

그러나 값 개체는 신원이없는 개체입니다. 하나의 공통 값 객체는 주소이지만 주소에는 ID가 없습니다. 그러나 데이터베이스 계층에서 우리는 복합 키를 가질 수 있습니다. 이 개념은 DDD에서 작동합니까? 그것은 도로명, 우편 번호 및 문 번호 (도시 및 도시와 같은 정보 생략)의 조합으로 주소를 식별 할 수있게합니다. 돈은 또 다른 가치 객체가 될 것입니다.

식별 할 수있는 필드가 하나도없는 개체에서 차이가있는 것처럼 보이고 값 개체는 실제 개체에 속하지 않는 경향이 있습니다. 예를 들어 "I"(내 이름으로 대체)는 신발 등을 착용 할 수 있지만 "나는"신발, 셔츠 등이 아닙니다 (http://www.lostechies.com/blogs/joe_ocampo/archive/2007/04/23/a-discussion-on-domain-driven-design-value-objects.aspx).

사물에 대해 생각하는 것이 올바른 방법입니까? 또한이 사고 방식으로 C#의 값/참조 유형 선택에이 방법을 적용 할 수 있습니다. 그래도 DDD 방식을 사용할 수 있습니까? 아마도 더 나은 당신이 일치하는 말 -

감사

Answer 1

나는 그들이 도메인 중심의 디자인에서 이해되는 나는이 문제에 대해 전문가로부터 멀리 나는 비록 당신이 (엔티티와 올바른 값 유형 구분의 개념을 생각 이 개념들에 대한 나의 이해). 그러나 C#에서 참조 또는 값으로 해당 개체를 모델링할지 여부를 결정할 때이를 결정 메트릭으로 사용하지 말라고 조언합니다.

값과 참조 형식의 주요 차이점은 값 형식이 메서드에 전달 될 때 값 형식이 복사된다는 것입니다. 이는 스택이 힙이 아닌 스택에 위치 할 확률이 높아지고 전달하는 데 더 많은 비용이들 수 있음을 의미합니다. 크기가 고려 요인이됩니다. 구조체는 크기가 16 바이트 (설명문 하단에 here)이어야하고 포괄적 인 주소 구조 (집 번호, 집 이름, 거리 지역, 도시, 국가 등 ...)가 있어야이 규칙을 쉽게 위반할 수 있습니다.

엔티티의 의미론 : value :: class : struct는 매우 유사하며 데이터를 모델링함으로써 많은 이점을 볼 수 있습니다 (동일한 주소에 사는 두 명의 사람은 이 아닙니다. 주소를 변경하면 한 사람의 주소가 변경되어 다른 사람의 주소가 변경되어서는 안되기 때문에 구조로 주소를 지정하면 이러한 구분이 적용됩니다. 반면 응용 프로그램의 모든 사람은 같은 사람을 가리켜 야합니다. 그러나 성능 및 메모리 고려 사항이 있습니다. 아마도 불변 클래스가 이러한 값 유형에 적합할까요?

요약 : DDD에서 개체와 값의 구분은 개체의 기준에 따라 결정됩니다. 코드에서 수행하려는 작업을 기반으로 코드를 작성해야합니다.