도메인 기반 디자인 - 저장소 및 집계 루트

Question

포럼이 포함 된 도메인 모델이 있습니다.

나는 포럼, 스레드 및 게시물 엔티티가 있습니다.

포럼은 독립 실행 형 엔터티입니다. 즉, 스레드는 집계의 일부로 포함되지 않습니다. 이것은 스레드가 특정 포럼 (스레드를 다른 포럼으로 이동할 수 있음)에 소유되어 있지 않기 때문입니다.

스레드 집계의 일부로 게시물을 모델링해야할지 모르겠다. 게시물은 스레드 없이는 존재할 수 없습니다. 스레드를 삭제하고 게시물을 스레드 집계의 일부로 지정하는 게시물을 삭제해야합니다.

유일한 점은 게시물을 편집 할 때 독립 실행 형으로 가져올 수 있다는 것입니다. 즉, ID로 게시물을 수정할 때입니다.

그래서 게시물 리포지토리가 스레드를 가져 오지 않고 스레드 엔터티의 메서드를 통해 올바른 게시물을 가져 오는 대신이 목적에 적합하다고 생각합니다.

별도의 게시물 저장소가있는 유일한 점은 게시물 (예 : addPost (Post))을 추가 할 때 스레드 ID가 게시 엔티티에 할당되었는지 확인해야한다는 것입니다. 합계를 사용하면 스레드 엔티티에 addPost 메소드 만있을 것입니다.

제한된 컨텍스트를 생각해야합니까? 게시 엔티티 및 리포지토리가있을 수 있으며 게시 엔티티도 포함하는 스레드 집계가 있습니까?

스레드/게시물 집계에 참여하지 않았다면 스레드를 삭제할 때 게시 삭제를 어떻게 처리합니까? thread 저장소에서 deleteThread (Thread)를 호출하고 post 저장소에서 deletePostsByThreadId (id)를 호출하는 서비스를 생성해야합니까?

여기에 DDD 방식이란 무엇입니까?

Answer 1

귀하의 경우 DDD가 좋은 아이디어 인 경우 궁금합니다. 나는 포럼이 본질적으로 데이터 지향적이라는 것을 의미한다. 어쩌면 가장 간단한 방법을 고려하고 고전적인 데이터 지향 기술을 사용하여 데이터를 쿼리해야합니다. (예 : LINQ, Hibernate, 일반 SQL, 엔티티 프레임 워크 또는 plateform에 따라 원하는 것)

아마도 도메인 계층이 필요하지 않거나 데이터를 보유하고있는 ForumDTO 클래스로 끝날 것입니다. 및 게시 또는 스레드에 대한 비즈니스 논리를 유지하는 포럼, 그것은 나에게 안티 패턴 같다.

당신은 어떻게 생각하십니까?

업데이트

난 당신이 에릭 에반스의 책을 읽어 보시기 바랍니다, 그것은 DDD는 정말 잘 맞는 복잡한 도메인의 좋은 사례가있다. 이 책을 읽은 후에 저는 배운 것을 적용하기가 열렬히 열심 이었지만, 데이터 지향적 인 접근이 더 적절한 경우를 보았습니다.

저에게는 포럼을위한 복잡한 도메인 로직이 거의 없으므로 데이터 레이어와 도메인 레이어간에 1 < -> 1 매핑을 사용하게 될 것입니다. 이는 제가 말했듯이 중복과 오버 헤드를 의미합니다.

도메인에 대한 설명을 보면 접근 방식이 데이터 지향적 인 것처럼 보입니다. 예를 들어, 직관적으로 포럼 HAS 스레드 및 스레드 HAS 게시물, 당신이 그것을 설명하는 도메인을 반영하지 않습니다 및 정규화 할 데이터베이스 스키마 (정규화됩니다)에 맞게 개체 모델을 정상화하는 것 같다.

포럼은 당신이 정말로 DDD 접근 방식을 사용하려는 경우, 당신은 당신의 엔티티에 저장소를 주입하고 도메인 객체 meaningfull 이름을 지정할 수 있습니다

(가 더 직관적) 집계의 루트로 최고의 클래스를 보인다 스레드에 따라 .GetLastPostOf (사용자 사용자), 요구 사항에 따라.

하지만 GetPostById 메소드를 가진 저장소가 있어야한다고 말하면 동의합니다.