Room 반환 시점

[waterricecake]

저번에 Player구현하다가 @thdwoqor 이랑 얘기한건데
방생성하기나 방 참가하기 외에 모든 행동이
우선적으로 방을 찾아야하다 보니 모든 서비스가 RoomManager를 갖게 되더라고요.

그래서 그때 얘기를 해봤던게 인터셉터로 먼저 방을 찾아줘서 반환을 해주어 서비스로 하여금 roomManager에 대한 의존성을 줄이면 어떨까 하였는데
이에대해서 다들 어떻게 생각하세요?
한다면 Controller는 이런 모습이 되더라고요

@RestController
@RequiredArgsConstructor
@RequestMapping("/chat")
public class ChatController {

    private final ChatService chatService;

    @GetMapping
    public ResponseEntity<List<ChatResponse>> findAllChat(
            @PlayerRoom final Room room,
            @PlayerInfo final String name
    ) {
        return ResponseEntity.ok(chatService.findAllChat(room, name));
    }

    @PostMapping
    public ResponseEntity<Void> saveChat(
            @PlayerRoom final Room room,
            @PlayerInfo final String name,
            @RequestBody final ChatRequest request
    ) {
        chatService.saveChat(room, name, request);
        return ResponseEntity.status(HttpStatus.CREATED).build();
    }
}

Room이 어떻게 보면 entity인데 이렇게 반환되도 싶나 해서 의문점이 생기더라고요.
근데 또 안그럼 RoomManager가 너무 많은 의존성을 갖게되고 추후에 다른 기능들 (투표 등등)에서도 결국 방을 다 찾아서 진행해줘야 할꺼 같아서 고민입니다.

branch (feature/9) 파서 일단 해봤는데 여러분 생각은 어떤지 물어보고 싶어서 discussion에 올려봤습니다.

[kpeel5839]

너무 좋은 의견 같아요! 그리고 지금처럼 이렇게 discussion으로 논의해 보는 것이 저는 처음해보는 경험인데 이것도 되게 괜찮네요. 역시 달리는 논술 왕이에요. 개인적인 생각으로는 이렇게 해도 괜찮을 것 같아요. 킹치만, 또 다른 방안을 내보자면 Event를 사용해 보는 것이 어떤가요? Room, Player 어떻게 보면 생명주기가 다르잖아요? 다른 애그리거트라고 보고 Event로 Room을 요청해서 반환받는 것도 나쁘지 않을 것 같아요. 제가 정확히는 모르지만 Player가 갖고 있는 Code를 넘기면 되니 가능하지 않나요? 혹은 현재의 구조에 문제가 있는 것은 아닌지 우리 한번 다시 검토해 보아요! 제가 아직 합류한지 얼마 되지 않아 도메인 분석이 되지 않은 상태라, 사실상 설계에는 문제가 없어 보이기는 하는데, 재백 씨랑 동연 씨가 다시 생각해 보았을 때 현재 구조에 문제가 있나요?

[waterricecake]

또 다른 방안을 내보자면 Event를 사용해 보는 것이 어떤가요?

오 Event를 사용한다면 이런 구조가 되는 건가요?

• event

@Getter
@RequiredArgsConstructor
public class RoomEvent {

    private final String code;
    private Room room;

    public void setRoom(final Room room) {
        this.room = room;
    }
}

• EventListener

@Component
@RequiredArgsConstructor
public class PublishEventListener {

        private final RoomManager roomManager;

    @EventListener
    public void findRoomByCode(final RoomEvent roomEvent) {
        final Room room = roomManager.findByCode(roomEvent.getCode());
        roomEvent.setRoom(room);
    }
}

• 사용부 (service)

    public void saveChat(final String code, final String name, final ChatRequest chatRequest) {
        final RoomEvent roomEvent = new RoomEvent(code);
        publisher.publishEvent(roomEvent);
        final Room room = roomEvent.getRoom();
        final Chat chat = room.getChat();
        final Player player = room.findPlayer(name);
        chat.save(Message.of(player, chatRequest.contents()));
    }

제가 Event에 대한 학습이 부족해서 인지 Event를 통해 인자를 받는 방법을 Setter를 통해 이렇게 받는 방법 말고는 잘 모르겠네요.

현재의 구조에 문제가 있는 것은 아닌지 우리 한번 다시 검토해 보아요! 제가 아직 합류한지 얼마 되지 않아 도메인 분석이 되지 않은 상태라, 사실상 설계에는 문제가 없어 보이기는 하는데, 재백 씨랑 동연 씨가 다시 생각해 보았을 때 현재 구조에 문제가 있나요?

현재 구조에서는 문제가 없다고 생각합니다. 킹치만, 저는 추후에 현재 Spring 메모리 영역에서 관리되고 있는 Room이 문제가 될것이라고 생각합니다. 게임이 끝나는 순간 방이 필요가 없기 때문에 영속성 계층까지 갈 필요가 없다고 생각하여 이와 같은 방식으로 저장하고 있습니다. 하지만 유저가 많아질 경우 Spring 자체에 부하가 많아질 것이고 이를 분리하여 따로 관리한 필요가 있다고 생각합니다. 따라서 Redis와 같은 in Memory DB를 통해 방이나 Chatting 정보를 관리하게 확장할 필요가 있다고 생각합니다. 이와 같은 상황에서 RoomManager 즉 RoomRepository가 모든 서비스에 의존성을 갖게 된다면 추후 확장을 하는데 많은 작업이 들어갈 것이라는 생각이 들어 의존성을 분리해보자는 생각이 들었던 것입니다.

또 다른 방법으로는 Chat과 Room을 분리하는 것도 가능할 것이라는 생각도 드네요. Chat이 Room에 있지 않고 Chat자체가 Room의 코드를 갖고 있다면 -> 즉 id를 통한 간접참조를 한다면 Room 없이도 ChatRepo에서 바로 Chat을 찾을 수 있도록 분리할 수도 있겠다는 생각이 드네요. 뭐가 더 좋은 방법인지는 잘 모르겠습니다.

[kpeel5839]

제가 Event에 대한 학습이 부족해서 인지 Event를 통해 인자를 받는 방법을 Setter를 통해 이렇게 받는 방법 말고는 잘 모르겠네요.

헉, 저는 바보같이 Event가 결과를 반환할 수 있을 거라고 순간 착각했네요. 이 부분은 착각으로 인해 잘못 전달된 것 같습니다.

현재 구조에서는 문제가 없다고 생각합니다. 킹치만, 저는 추후에 현재 Spring 메모리 영역에서 관리되고 있는 Room이 문제가 될것이라고 생각합니다. 게임이 끝나는 순간 방이 필요가 없기 때문에 영속성 계층까지 갈 필요가 없다고 생각하여 이와 같은 방식으로 저장하고 있습니다. 하지만 유저가 많아질 경우 Spring 자체에 부하가 많아질 것이고 이를 분리하여 따로 관리한 필요가 있다고 생각합니다. 따라서 Redis와 같은 in Memory DB를 통해 방이나 Chatting 정보를 관리하게 확장할 필요가 있다고 생각합니다. 이와 같은 상황에서 RoomManager 즉 RoomRepository가 모든 서비스에 의존성을 갖게 된다면 추후 확장을 하는데 많은 작업이 들어갈 것이라는 생각이 들어 의존성을 분리해보자는 생각이 들었던 것입니다.

그러네요, 왜 Room을 저장하지 않고 in-memory 방식으로 진행하고 있는지 납득이 됩니다. 하지만, 추후 기획에 수정사항이 생겨 이전 게임의 기록을 남기기 위해서는 영속성 계층에 저장하는 것까지는 괜찮지 않을까? 라는 생각도 조금 드네요. 이는 제가 기획에 대해서 깊숙히 알고 있지 못해 생기는 애로사항인 것 같기도 합니다.

또 다른 방법으로는 Chat과 Room을 분리하는 것도 가능할 것이라는 생각도 드네요. Chat이 Room에 있지 않고 Chat자체가 Room의 코드를 갖고 있다면 -> 즉 id를 통한 간접참조를 한다면 Room 없이도 ChatRepo에서 바로 Chat을 찾을 수 있도록 분리할 수도 있겠다는 생각이 드네요. 뭐가 더 좋은 방법인지는 잘 모르겠습니다.

이러한 의견에서 비롯하여, 이 말씀은 굉장히 좋은 의견인 것 같아요. Room과 Chat이 너무 강하게 연결되어 있어 이러한 문제가 발생하는 것 아닌가 싶긴하니까요. 근데, 강하게 연결되어 있는게 당연한 것 같기도하고...

쨌든, 다시 돌아와서 생각하면 Room을 영속성 계층에 저장하게 된다면, 현재의 흐름은 되게 자연스러운 것 같아요. Room->Chat 이잖아요. 그러니까 findAllChat, saveChat과 같은 것은 사실 아래와 같은 플로우로 진행되는 것이죠.

• 조회

1. Room을 찾아온다.
2. Room.getChats()를 통해 방에 속한 chating 내역들을 가져온다.

• 저장

1. Room을 찾아온다.
2. Room.addChat(chat)을 통해 채팅을 방에 포함시켜준다.

이런 식으로 되어도 자연스럽지 않을까요?

사실 달리가 제안해준 현재의 방식도 너어무 좋은 것 같아요. osiv만 잘 신경써준다면, 트랜잭션을 길게 물고 있지 않고, @PlayerRoom 어노테이션을 사용하지 않으면 앞단에서 Room을 조회하는 일도 없을테니까요. 하지만 다양한 의견을 나누어보고 싶어서 길게 말씀드려봤습니다.

[waterricecake]

그러네요, 왜 Room을 저장하지 않고 in-memory 방식으로 진행하고 있는지 납득이 됩니다. 하지만, 추후 기획에 수정사항이 생겨 이전 게임의 기록을 남기기 위해서는 영속성 계층에 저장하는 것까지는 괜찮지 않을까? 라는 생각도 조금 드네요. 이는 제가 기획에 대해서 깊숙히 알고 있지 못해 생기는 애로사항인 것 같기도 합니다.

처음에는 유저가 자신이 했던 플레이를 다시 볼 수 있게 하는 것도 좋겠다는 의견이 있었습니다. 하지만 저희의 기획의 핵심이 로그인이 필요없는 마피아 게임인 만큼 사용자가 사이트에 다시 방문 했을때 그 유저가 유저인지 확인할 방법이 존재하지 않죠. 그래서 저는 영속성 계층이 필요한가라고 생각했었습니다.

근데 매튜의 말처럼 추후 기획이 바뀔 가능성도 있으니 한번 백엔드 끼리만이 아닌 전체적으로 회의를 해보는 것이 좋을것 같습니다. 저도 로그인 기능을 통해 플레이를 저장하고 로그인 안해도 똑같이 플레이 할 수 있게 하는 것도 재미있는 방법이라 생각했기 때문입니다. 게임이라면 이전 매드무비나 POTG같은건 보면 재밌으니까요. 이건 또 다른 생각인데 플레이어 별로 마피아의 경우 시민을 낮 투표로 죽일 경우 점수를 주거나 시민의 경우 낮 투표에서 마피아를 투표할 경우 또 의사가 살리거나 경찰이 맞추면 점수를 주어서 결과창에 잘한 플레이어를 나열하는 것도 재미있는 방법이겠다 생각이 들더라고요. 이런 부분은 영속성 계층에 저장하여 자신의 실력이 어느정도인지 또 점수별로 캐릭터 디자인을 바꿔준다 든지 하면 유저의 사용율이 올라갈 수 있겠지요. 뭐 물론 MVP에서 생각할 부분은 아니긴 하지만요 ㅋㅋ

사실 달리가 제안해준 현재의 방식도 너어무 좋은 것 같아요. osiv만 잘 신경써준다면, 트랜잭션을 길게 물고 있지 않고, @PlayerRoom 어노테이션을 사용하지 않으면 앞단에서 Room을 조회하는 일도 없을테니까요. 하지만 다양한 의견을 나누어보고 싶어서 길게 말씀드려봤습니다.

저도 이부분이 너무 신경쓰여서 Transaction이 Controller 앞까지 가는 거니까 신경써줘야 할꺼 같더라고요. 그래서 매튜가 제안해준 Event도 괜춘하겠다 생각했는데 setter로 건내주는게 너무 억지스럽다는 생각이 들기도 하더라고요. 그래서 간접참조 방식을 생각하기도 했습니다.

저도 꼭 RoomManager를 분리하자는 의견은 아닙니다. 매튜 말데로 Room과 Chat은 강하게 연결될 수 밖에 없죠 저는 처음에는 Service가 분리될 필요가있나라는 생각도 들었습니다 ㅋㅋ 이 부분은 좀더 많이 얘기해보고 결정하도록 하죠

[kpeel5839]

처음에는 유저가 자신이 했던 플레이를 다시 볼 수 있게 하는 것도 좋겠다는 의견이 있었습니다. 하지만 저희의 기획의 핵심이 로그인이 필요없는 마피아 게임인 만큼 사용자가 사이트에 다시 방문 했을때 그 유저가 유저인지 확인할 방법이 존재하지 않죠. 그래서 저는 영속성 계층이 필요한가라고 생각했었습니다.

이해했습니다.

근데 매튜의 말처럼 추후 기획이 바뀔 가능성도 있으니 한번 백엔드 끼리만이 아닌 전체적으로 회의를 해보는 것이 좋을것 같습니다. 저도 로그인 기능을 통해 플레이를 저장하고 로그인 안해도 똑같이 플레이 할 수 있게 하는 것도 재미있는 방법이라 생각했기 때문입니다. 게임이라면 이전 매드무비나 POTG같은건 보면 재밌으니까요. 이건 또 다른 생각인데 플레이어 별로 마피아의 경우 시민을 낮 투표로 죽일 경우 점수를 주거나 시민의 경우 낮 투표에서 마피아를 투표할 경우 또 의사가 살리거나 경찰이 맞추면 점수를 주어서 결과창에 잘한 플레이어를 나열하는 것도 재미있는 방법이겠다 생각이 들더라고요. 이런 부분은 영속성 계층에 저장하여 자신의 실력이 어느정도인지 또 점수별로 캐릭터 디자인을 바꿔준다 든지 하면 유저의 사용율이 올라갈 수 있겠지요. 뭐 물론 MVP에서 생각할 부분은 아니긴 하지만요 ㅋㅋ

오우... 이거는 확실히 경쟁력 있겠는데요? 장난아닌데?

저도 이부분이 너무 신경쓰여서 Transaction이 Controller 앞까지 가는 거니까 신경써줘야 할꺼 같더라고요. 그래서 매튜가 제안해준 Event도 괜춘하겠다 생각했는데 setter로 건내주는게 너무 억지스럽다는 생각이 들기도 하더라고요. 그래서 간접참조 방식을 생각하기도 했습니다. 저도 꼭 RoomManager를 분리하자는 의견은 아닙니다. 매튜 말데로 Room과 Chat은 강하게 연결될 수 밖에 없죠 저는 처음에는 Service가 분리될 필요가있나라는 생각도 들었습니다 ㅋㅋ 이 부분은 좀더 많이 얘기해보고 결정하도록 하죠

맞아요. 저도 결과를 반환할 수 있는 줄 알고 말씀드렸던 것인데, Setter를 이용하는 것은 좀 많이 억지스럽다는 생각이 들었어요. 해당 방식보다는 앞단에서 Room을 가져오는 방법이 더 좋은 방법인 것 같습니다.

좋은 의견 교류였어요! 고민들이 재미있었네요. 계속해서 discussion 잘 활용해봅시다.