ReadStatus,UserStatus,BinaryContent 도메인 추가(왜 추가하는거고, 어떤 역할을 하는지?)

 

ReadStatus(읽음 상태)

• 사용자가 채널별 마지막으로 메시지를 읽은 시간을 표현하는 도메인
• 사용자별 각 채널에 읽지않은 메시지를 확인하기 위해 활용
• (userId,channelId) 당 1개 생성되는 도메인

 

왜 ReadStatus를 추가해야하는가?

 

1. User에 넣을경우: 어떤 채널의 마지막 읽음인지 알 수 없음

User.lastReadAt

 

2. Channel에 넣을경우: 사용자별 읽음 상태를 구분할 수 없음.

 

3. Message 마다 읽음 처리: 사용자 x 메시지 수  =  너무 많은 데이터

 

User 1 ─── * ReadStatus * ─── 1 Channel

 

• 한 사용자는 여러 채널을 읽는다
• 한 채널은 여러 사용자에게 읽힌다
• 각 (사용자, 채널) 조합마다 읽음 상태가 하나씩 존재

 

[ReadStatus 정리]

User 1
 ├─ ReadStatus (Channel 1)
 ├─ ReadStatus (Channel 2)
 └─ ReadStatus (Channel 3)

• 한 유저는 여러 채널을 가진다.
• 여러 채널 각각의 메시지 읽음 상태를 확인하기 위해 여러 읽음 상태를 가질 수 있다.

Channel 1
 ├─ ReadStatus (User A)
 ├─ ReadStatus (User B)
 └─ ReadStatus (User C)

• 한개의 채널은 여러 사용자를 가진다.
• 여러 사용자 각각의 메시지 읽음 상태를 확인하기 위해 여러 읽음 상태를 가질 수 있다.

---

UserStatus(사용자 온라인 상태)

• 사용자 별 마지막으로 확인된 접속 시간을 표현하는 도메인 모델
• 한 사용자당 하나의 UserStatus(1대1 관계)

createdAt: 최초 로그인 시간

updateAt: 재접속 시간

 

updateAt을 이용해서 사용자의 온라인상태를 확인할 수 있다.

ex) (현재시간 - 마지막 접속시간) <= 5  = 온라인이다

 

---

BinaryContent

• 사용자 프로필 이미지
• 메세지에 첨부될 파일
• 수정이 불가능한 모델 : updateAt 필드는 정의하지 않는다.
• 사용자는 프로필 이미지를 0개이상 갖는다.
• 메세지는 파일을 0개 이상 갖는다.

User, Message 도메인 모델과의 의존 관계 방향성을 잘 고려하여 id 참조 필드를 추가해라

• BinaryContent에 User나 Message 객체를 필드로 받으면 결합도가 올라간다.
• ex) User 구조 변경되면 BinaryContent에도 영향이간다.

 

-BinaryContent에 User,Message 객체를 필드로 받을시,

[문제점1]

binaryContent.getUser().getEmail();
binaryContent.getMessage().getChannelId();

• BinaryContent의 책임이 커진다.
• SRP 붕괴

 

[문제점2]

public class User {
    private UUID id;
    private LoginInfo loginInfo; // 구조 변경
}

 

• 구조변경시, BinaryContent 수정이 발생한다 -> 결합도 높음.

 

[문제점3]

BinaryContent content = new BinaryContent();
content.setUser(new User(...));      // 필요
content.setMessage(new Message(...)); // 필요

• BinaryContent 하나 테스트하려고할때 User,Message를 전부 만들어야한다.

 

[따라서 ID 참조만 하는게 좋다.]

public class BinaryContent {

    private UUID id;
    private Instant createdAt;

    // ID 참조만
    private UUID userId;
    private UUID messageId;
}