복합 값 객체를 작성하는 방법은 무엇입니까?

Question

방금 ​​DDD를 배우기 시작했습니다. 그래서 바보 같은 질문에 사과드립니다 ...

그래서 나는 Post 개체를 가지고 있습니다. 괜찮아 보인다. 하지만 tags이어야합니다. 코드에서는이 (루비 코드)과 같습니다

class Post 
    attr_reader :tags 
    attr_reader :title 
    attr_reader :text 
    # ... 
end 

class Tag 
    attr_reader :name 
    attr_reader :description 
    # ... 
end 

태그 실체로 이해가되지 않습니다. 나는 tag 그 자체를 필요로하지 않는다. 하지만 게시 용 저장소를 구현하려면 어떻게해야합니까? 같은 저장소에

1 빌드 태그 : 나는이 변종을 발견했다. 좋아요 :

# PostRepository 
def find(id) 
    # getting post data from storage here 
    # getting tags data 
    Post.new(title, text, tags_data.map { |tag_data| Tag.new(tag_data[:name], tag_data[:description])) 
end 

하지만보기 흉하게 보입니다. 이유를 분명히 말할 수 없습니다.

2. 태그 용 별도 리포지토리를 만듭니다.

# PostRepository 
def find(id) 
    # getting post data from storage here 
    Post.new(title, text, tag_repository.find(tag_ids)) # or tag_names or tag_something 
end 

그러나 가치 객체를위한 별도의 저장소를 만드는 것이 괜찮습니까?

DDD에 따른 올바른 방법은 무엇입니까?

UPD : 반면에 사용 가능한 모든 태그를 가져야합니다. 게시물로 태그를 변경할 필요가 없습니다. 그리고 태그의 이름은 신분처럼 보입니다. 어쩌면 근본적으로 잘못 되었나요? 태그가 엔티티일까요?

UPD2 :

이 문제는 내 디자인 기술은 매우 가난한 것을 나에게 보여줍니다. 그것 때문에, 내 질문에는 두 가지 질문이 있습니다. 그들은 다음과 같습니다 :

1. 엔티티의 저장소 내부에 값 객체를 빌드하는 올바른 방법은 무엇입니까?
2. 내 문제의 가치와 실체의 차이를 보는 방법. 결국 분명해 보입니다. 지정된 조건에 따라 태그는 값입니다. Post의 저장소에 의해 빌드 된 것은 괜찮습니다.

그러나이 조건은 열악한 분석 결과입니다. 내가 더 크게 보일 수 있다면 그 태그가 자신의 라이프 사이클임을 알 수 있습니다. 게시물의 컨텍스트에서 태그는 변경 불가능합니다.

Answer 1

태그는 대부분 도메인의 일반 값 개체 일뿐입니다. 태그에는 자체 라이프 사이클이있는 경우 엔티티가 될 수 있습니다. 솔직히 말해서 나는 도메인의 경우라고 생각하지 않습니다. 각 태그를 동일한 속성으로 다른 사본으로 바꿀 수 있기 때문입니다.

도메인 리포지토리에 쿼리 태그에 메서드를 추가 할 수 있습니다. DDD 집계 규칙 위반이 아닙니다. 집계는 실제로 일관성에 관한 것입니다. 집계 컨텍스트 외부에서 수정할 수 있으면 리포지토리는 집계의 일부를 반환하면 안됩니다. 그러나 읽기 전용으로 집계의 값 개체를 명시 적으로 반환 할 수 있습니다 (예 : 선택한 기간 내의 모든 게시물의 모든 태그를 수집하는 등). 그 외에도 쿼리 메서드는 효율성을 위해 리포지토리에 배치해야합니다.즉, 아마도 CQRS 원칙에 따라 별도의 읽기 모델 (예 : nosql db 사용)을 사용하는 것이 가장 좋은 해결책 일 것입니다. 이렇게하면 쿼리 요구에 맞게 모델을 명시 적으로 조정할 수 있으므로 매우 효율적입니다.