가치 객체 관계를 모델링하는 방법?

Question

문맥:
엔터티 북이 있습니다. 책에는 하나 이상의 설명이있을 수 있습니다. 설명은 가치 객체입니다.

문제:
설명은 다른 설명보다 더 구체적 일 수 있습니다. 예를 들어 설명에 책의 내용이 포함되어있는 경우 표지가 어떻게 보이는지 설명하는 것보다 표지가 어떻게 보이는지 설명합니다. 나는 이것을 모델링하는 방법과 저장소를 저장하는 방법을 모른다. 이러한 관계를 아는 것은 책의 책임이나 책 설명의 책임이 아닙니다. 다른 객체는 이것을 처리 한 다음 저장소에 관계를 저장하도록 요청할 수 있습니다. 그러나 BookRepository.admorespecificdescription (설명, morespecificdescription)은 저장소를 저장하기가 어려워 보입니다.

DDD에서 그런 일이 어떻게 처리됩니까?

Answer 1

다른 두 가지 대답은 한 방향 (+1 btw)입니다. 원래 질문을 편집 한 후에 들어오고 있습니다. 그래서 여기에 내 두 센트가 있습니다 ...

나는 값 객체를 다른 엔티티들 사이에서 공유 할 수있는 두 개 이상의 속성을 가진 객체로 정의합니다. 그것들은 단일 집계 루트 내에서만 공유 할 수 있습니다. 괜찮습니다. 그들이 공유 할 수 있다는 사실.

예제를 사용하려면 "설명"을 값 객체로 정의합니다. 그것은 여러 책들 사이에서 여러 속성을 가진 "설명"을 공유 할 수 있음을 알려줍니다. 실제 세계에서는 우리 모두가 책을 저술하거나 출판 한 사람의 마스터가 쓴 독특한 설명을 가지고 있다는 것을 알고 있기 때문에 의미가 없습니다. 헤헤. 따라서 설명은 실제로 가치 객체가 아니라고 주장합니다. 그러나 그 자체는 책 내부의 추가 엔티티 객체라고 주장합니다. 재 릴리스, 새로운 개정기 등의 책조차도 약간의 변화를 설명하는 설명이 약간 다릅니다.

나는 당신의 질문에 대한 답변 - 설명 엔티티 객체를 만들고 메인 책 엔터티 집계 루트 뒤에 그들을 보호합니다 (예 : book.getDescriptions () ...). 이 답변의 나머지 부분은 저장소에서 가치 객체를 처리하는 방법을 다루고 있습니다. 다른 사람들은이 게시물을 읽습니다 ...

저장소에 가치 객체를 저장하고 검색하기 위해, 우리는 "데이터베이스 우선"모델링 접근 방식에서 DDD 접근 방식으로 전환했을 때 나 자신과 씨름 한 동일한 영역에 침식하기 시작합니다. 나는 자신이 DB에 값 객체를 저장하는 방법에 대해 이것을 사용하고 신원없이 검색했습니다. 물러서서 내가하고있는 일을 깨달을 때까지 ...

도메인 중심 디자인에서는 데이터 저장소가 아닌 도메인의 값 객체를 모델링하는 것입니다. 그것이 핵심 문구입니다. 그것은 당신이 데이터 저장소에서 독립 객체로 저장할 값 객체를 설계하지 않는다는 것을 의미합니다. 원하는대로 저장할 수 있습니다!

주소 () 인 값 객체의 일반적인 DDD 예제를 봅시다. DDD는 값 객체의 정의가 객체의 고유성을 만들기 위해 누가 속성을 요약 한 사람의 객체이기 때문에, 메일 링 주소는 완벽한 값 객체 예제임을 제시합니다. 속성이 변경되면 다른 값 객체가됩니다. 그리고 동일한 값 객체 9Teh의 속성)를 다른 엔티티들 사이에서 공유 할 수 있습니다.

우편 주소는 지구상의 특정 위치의 길고 위도입니다. 여러 사람이 주소에 살 수 있으며 누군가가 움직일 때 새로운 사람들이 동일한 우편 주소를 차지하도록 이제 동일한 가치 객체를 사용합니다.

따라서 주소 정보가있는 MailingAddress () 객체가있는 person () 객체가 있습니다. Get/Update/Create Methods/Services를 사용하여 내 Person () 집계 루트 뒤에 보호됩니다.

이제 우리는 어떻게 그것을 저장하고 같은 가정의 사람들 사이에서 그것을 공유합니까? 아, DDD가 있습니다 - 당신은 당신의 DDD에서 바로 데이터 저장소를 모델링하지 않습니다 (하지만 좋을 것입니다). 그렇게 말하면, 당신은 간단하게 당신의 사람 객체를 제시하는 단일 테이블을 만들고, 그것의 우편 주소의 열이 있습니다. 정보를 데이터 저장소에서 Person () 및 MailingAddress () 객체로 되돌려 놓고 생성/업데이트 작업 중에 분할하는 것은 저장소의 임무입니다.

네, 이제 데이터 저장소에 중복 데이터가 있습니다. 동일한 우편 주소를 가진 3 명의 사람 () 엔티티는 이제 해당 값 객체 데이터의 세 가지 사본이 3 개 있습니다. 괜찮습니다! 가치 객체는 아주 쉽게 복사하고 목격해야합니다. "복사"는 DDD 플레이 북의 최적 단어입니다.

요약하면, 도메인 드라이브 설계는 객체의 실제 비즈니스 사용을 나타내는 도메인 모델링에 관한 것입니다. 귀하는 개인 () 엔티티와 MailingAddress 값 객체를 신청서에서 다르게 표시하므로 별도로 모델링합니다. 당신은 그들에게 복사 된 데이터를 유지합니다.

위의 모든 것은 엄격한 DDD입니다. 그러나 DDD는 살아야 할 규칙이 아니라 단지 "제안"이라는 것을 의미합니다. 그렇기 때문에 당신은 나 자신과 다른 많은 사람들이 한 일을 자유롭게 할 수 있습니다. 복사 된 데이터가 마음에 들지 않으면 유일한 옵션은 MailingAddress ()에 대한 별도의 테이블을 만들고 ID 열을 고수하고 MailingAddress () 객체를 업데이트하여 이제 해당 ID에 대한 ID를 갖도록 업데이트 할 수 있다는 것입니다. 당신은 그 신원을 사용하여 그것을 공유하는 다른 사람 () 객체에 연결하기 위해서만 알고 있습니다 (개인적으로 쿼리 속도를 높이기 위해 개인적으로 3 번째 다수의 관계 테이블을 좋아합니다). 당신은 그 아이덴티티 (즉, 내부 수정 자)가 집계 루트/도메인 외부에서 노출되지 않도록 마스킹 할 것이므로 다른 레이어 (예 : 응용 프로그램 또는 UI)는 가능한 경우 MailingAddress의 신원 열을 알지 못합니다. 또한 MailingAddress를위한 전용 저장소를 만들고 PersonService 계층을 사용하여 올바른 개체 인 Person.mailingAddress ()에 결합합니다.

rant에 대해 죄송합니다 ... :)

Answer 2

첫째, 리뷰는 엔티티 여야한다고 생각합니다.

둘째, 왜 리뷰 간의 관계를 모델링하려고합니까? 나는 그들 사이의 자연스러운 관계를 보지 못한다. "보다 구체적"은 관계로 유용하기에는 너무 모호합니다.

상황을 모델링하는 데 어려움이 있다면 관계가 없을 수도 있습니다.

Answer 3

나는 Jason에 동의합니다. 리뷰 가치 객체를 만들기위한 당신의 이론적 근거가 무엇인지 모르겠습니다.

BookReview에 BookReviewContentItems가있어서 BookReview에 전화를 걸어 내용 항목 모음 쿼리를 기반으로 메소드가 결정되는 방법이 충분한 지 결정할 수 있도록 BookReview의 메소드를 가질 것으로 기대합니다.