도메인 기반 디자인 : 대용량이지만 동작이 적은 관계 모델링 방법

Question

두 개의 엔터티 User 및 Item이 있다고 가정 해 봅니다. 이 두 엔티티 간의 도메인에서 유일한 동작은 사용자가 항목을 좋아할 수 있다는 것입니다. 사용자가 원할 수있는 아이템의 수에 제한이 없으므로,이 다 대다 관계는 커질 수 있습니다.

사용자가 모델에서 좋아하는 항목의 목록 또는 다른 방법으로 실적을내는 것이 바람직하지 않다고 생각합니다. 그 이유는 잠재적으로 큰 항목 컬렉션을로드해야하기 때문입니다. 하나의 항목 만 추가하십시오. 도메인 디자인의 관점에서 볼 때 항목 또는 사용자 컬렉션의 존재를 요구하는 동작이 없으므로 각 엔티티를 해당 필드에서 다른 엔티티 참조로 가져 오는 것도 의미가 없습니다.

사용자가 좋아하는 항목 목록과 항목을 좋아하는 사용자 목록을 UI에 표시해야하므로이 관계를 유지해야합니다. 요구 사항은 읽기 모델에서 제공 할 수 있지만이 관계를 유지하기 위해 여전히 도메인 개념이 필요하므로이를 지속 할 수 있습니다.

내가 생각해 볼 수있는 한 가지 방법은 집계의 관계 유형을 소개하고, UserLikeItem을 말하고, 메소드 user.like (item)가 UserLikeItemRepository를 사용하여 유지할 수있는 UserLikeItem의 인스턴스를 반환하는 것입니다.

유효한 해결책입니까? DDD에서 이러한 유형의 크고 비 행동적인 관계를 모델링하는 자연스러운 방법은 무엇입니까?

Answer 1

나는 이것에 발걸음을 옮길 것이다 : IMO에는 "도메인 모델"에 살아 있지 않은 행동이 없으며, 대다수의 개념에 행동이 없다면 " 도메인 모델 "이라면 도메인 모델이 아닌 transaction script 패턴을 찾아야합니다.

당신의 질문을 "나는 많은 방법으로 많은 관계를 유지합니까?"이 질문에 우리는 여러 답변을했습니다. 하나는 당신이 다른 사람이 언급 한 것입니다. 수업.

도메인 모델과 퍼시스턴스 백엔드의 객체 지향 표현은 두 가지로 구분됩니다. 도메인 모델은 먼저 동작이므로 도메인 모델에 동작을 생각한 다음 해당 동작의 영향을받습니다. 그렇지 않으면 필요한 것은 "지속성 백엔드의 객체 지향 표현"입니다. (DTO)

도메인 모델에 대한 사례가있을 때 까다로워 지지만 몇 가지 개념은 빈약하고 행동이 부족하지만 다른 날 질문 :

Answer 2

'좋아요'는 도메인 사실로, Entity로 나타낼 수 있습니다.
아이템은 좋아요 -> 아이템에는 좋아요 컬렉션이 있습니다.
이 컬렉션은 LikeCount 속성이 있고 Likes 컬렉션이 Repository 쿼리 (Item.AddLikeFrom (user) 및 Item.RemoveLikeFrom (user) 메소드에서만 사용됨)에 대한 선택 사항 인 경우 likes 추가 및 삭제에만 필요합니다.

관계가 비 행동 적이지만 사실 관계 측면 중 하나의 동작입니다.

Answer 3

나는이 시나리오를 얼마 전에 접 했으므로 여기에 필자의 의견이 있습니다. 사용자 및 항목은 항목에 userId가 있더라도 서로에 대해 모르고/걱정하지 않는 다른 집계의 일부입니다. "Like System"(LS)은 에서부터 까지과 같은 다른 집계 추적을 추적합니다.

LS는 사용자 또는 항목에 대해별로 신경 쓰지 않지만 사용자가 아닌 다른 뭔가가 마음에 들지 않는 사례를 볼 수는 없지만 좋아요는 항상 userId를 암시합니다 (전체 사용자 개념) 및 주제 (항목, VIdeo, 그림, 포스트 등).

LS는 사용자 ID와 특정 유형의 다른 itemId (LS가 항목이 결합되지 않도록하려는 경우 문자열 일 수 있음)의 연결을 유지합니다. 사용자가 명령을 내릴 때마다 RegisterLikeForItem {UserId, ItemId, ItemType}이 (가) 발급됩니다. LS 처리기는 해당 정보를 저장 한 다음 이벤트를 게시합니다 UserLikedItem. 처리기 중 하나는 얼마나 많은 사용자가 해당 항목을 좋아하는지 계산할 수있는 카운터입니다. 다른 핸들러는 한 사용자가 좋아하는 항목 목록을 만들 수 있습니다 (UI에 의해 쿼리됩니다).

각 처리기는 하나의 유스 케이스를 제공하며 각각 고유 한 저장 공간을 가지고 있습니다. 꽤 복잡해 보이지만 실제로는 간단합니다 (하나의 유스 케이스는 핸들러와 스토리지가 필요합니다). 그리고 모두의 베팅은 매우 유연하고 유지 보수가 용이합니다. 그리고이 시스템은 1 개 또는 1000 개의 항목 유형으로 작동합니다.