2013-04-24 4 views
3

최근에 DDD에 대해 배우고 있었고 개념을 이해하지 못했습니다. 샘플 블로그 애플리케이션에 대해 몇 가지 질문이 있습니다. User, Blog, PostComment : 도메인 구동 디자인 (샘플 블로그 애플리케이션)

이의 블로그 시스템에 네 개의 도메인 객체가 있다고 가정 해 봅시다. 하나의 UserBlog, Blog은 복수 Post 개의 엔터티를 가질 수 있으며 Post은 많은 Comment 엔터티를 가질 수 있습니다.

class Blog { 
    private User; 
    private List<Post> posts; 
} 

class Post { 
    private List<Comment> comments; 
} 

class BlogRepository { 
    public void saveBlog(Blog blog); 
    public void findBlogById(long id); 
    public void getAllBlogs(); 
} 

오전 내가 바로이 같은 집계 루트와 저장소를 설계 :

내 디자인 Blog가 집계 루트 점이다?

나는 모든 Blog 개체에 대해 사용자가 추가 한 모든 Comment 개체를 얻을 수있는 몇 가지 요구 사항을 가지고, 또한 UserComment 자신의/그녀를 수정할 수 있습니다.

내 질문에 어떻게 이러한 요구 사항을 구현할 수 있습니까?

+1

db 스키마 설계와 같은 도메인 모델링을 생각하지 않도록하십시오. 1 대 1 또는 1 대 다수 관계는 전형적인 관계형 DB 사고입니다. DDD에는 아무 것도 없습니다. – MikeSW

답변

2

제시하는 모델은 도메인을 반영하지만 최적의 DDD 구현은 아닙니다. DDD의 경우 엔터티 간의 관계를 고려하는 것 외에도 트랜잭션 일관성 경계도 고려해야합니다. 결과적으로 Blog, PostUser을 각각 ID로만 참조하는 별도의 집계로 설계하는 것이 좋습니다. 또한 Blog 엔티티에 게시물 모음이 있어야 할 이유가 없습니다. 블로그 전체를로드 할 필요가 없으며 비헤이비어가 여러 게시물에 걸쳐서는 ​​안됩니다. 대신 블로그 게시물의 하위 집합을로드하기 위해 페이지 매김 저장소 메소드를 제공하십시오. 그러나 Comment은 값 개체가 될 수 있으므로 주석 컬렉션은 Post 집합체와 함께로드해야합니다. 사용자에 대한 모든 주석을 얻는 가장 쉬운 방법은 엔터티의 동작과 쿼리가 충돌하지 않도록 read-model을 반환하는 리포지토리 쿼리 메서드를 만드는 것입니다. 집합체 설계에 대한 자세한 내용은 Effective Aggregate Design을 참조하십시오.

+2

DDD를 사용하여 블로그 엔진을 개발하고 있으므로이 문제에 대해 많은 생각을했으며 Comment는 가치 객체가 아니라고 말할 수 있습니다. 엔티티입니다. 댓글 자체는 게시물 및 포스트 AR과 직접적인 관련이 없습니다 (여기서는 도메인에 대해서만 말하고 있습니다). 댓글에 대해 알만한 이유가 없습니다. 게시물과 댓글은 서로 붙어 있지만 아주 독립적입니다. 하나는 다른 기능 없이도 작동 할 수 있습니다. 읽기 모델은 그것들을 "결혼"하고, 그때조차도 문맥에 대한 관련 비트들만을 사용한다. – MikeSW

+0

그건 분명히 의미가 있습니다. 처음에는 VO로 주석을 모델링 한 다음, 주석을 둘러싼 기능이 더 많이 호출되어 AR에 "승격"될 수있을 때 진화 할 수 있습니다. – eulerfx

+0

@MikeSW : 내가 CommentRepository가 있어야한다는 뜻인가요? – davenkin

관련 문제