Room, Vote, JobTarget, Chat 분리에 대해서

[waterricecake]

Redis 도입전 해당 부분들이 분리될 필요가 없기에 같이 구현하였지만 Redis를 도입하면서 든 생각이 Chat은 후에 Pub/Sub 구조를 가져가게 될 것인데 분리를 해야하지 않을까 라는 생각을 가지게 되었습니다.

왜냐하면 PUB/SUB은 저장한 채팅들을 Queue형식으로 빼주는 방법으로 구현되기 때문입니다. 이때문에 Room을 그냥 RedisHash로 저장하는 방식은 어울리지 않다고 생각하였습니다.

이때문에 Chat을 분리하는 게 좋겠다고 생각했는데 하다보니 Vote, JobTarget또한 분리되는게 좋겠다고 생각이 들더라고요.
그이유는 Room과 생명주기가 다르기 때문이라고 생각합니다.

Vote와 JobTarget은 각각 투표, 밤 상태가 종료시 초기화 되는데 이 초기화가 어떻게 보면 이 Vote, JobTarget의 생명주기가 됩니다. 그런데 만약 Room에 같이 있을 경우 플레이어 하나 바뀔때마다 새로 room 전체를 다시 넣어주고 하는 작업이 들더라고요. 그것보다는 Vote, JobTarget을 분리하여 관리하는 것이 더 자연스럽다고 생각하게 되었습니다.

이러한 방법을 채택한다면 프로젝트 초기 제가 고민하였던 RoomManager의 의존성 문제도 해결할 수 있을 것이라 생각합니다.

[kpeel5839]

애그리거트 단위로 나누는 것은 무조건 필요하다고 생각했어요.

최근들어 제가 이벤트 스토밍을 진행해보았는데요. 해당 기법이 도메인에 대한 이해도도 높일 수 있고, 도메인을 애그리거트 단위로 나누는데 도움을 많이 주는 것 같더라고요.

그래서 건의 드려봅니다. 제가 아직까지는 여러분들보다 도메인에 대한 이해도도 떨어지고 이참에 애그리거트 단위로 도메인을 분리하고 서로 간의 의존성도 완전히 정리할겸 이벤트 스토밍을 한번 해보는 것 어떨까요?

부정적인 피드백도 괜찮아요! 아무래도 이미 도메인이 구성되어 있는 상태에서 이벤트 스토밍을 한다는 것 자체가 과한 비용을 투자하는 것일수도 있으니까요! 차라리 만나서 컴팩트하게 1~2시간 정도, 현재 도메인을 애그리거트 단위로 분리하는 것 정도로 충분할 것 같기도 하고요.

[thdwoqor]

지금 룸에 모든게 다들어가있어서 분리하면 괜찮을거같아요
이벤트 스토밍은 새로 오신 프론트 분들이 도메인 이해를 높이는 데 도움이 될 것 같아요.
기존에 있던사람도 서로 잘못 이해하고 있던 부분을 정리하는 데 도움이 될 같구요

[kpeel5839]

오호! 재백짱은 동의하는군요

[waterricecake]

아 그이벤트가 그 이벤트가 아니구나 ㅋㅋㅋㅋㅋㅋ 그러면 다음 개발자 회의 전에 한번 모여서 정리해보죠! 언제가 좋슴까?
아니면 재백짱의 말은 이벤트 스토밍을 개발자 회의때 프론트분들과 함께 하자는 의미인가요?

[kpeel5839]

저는 괜찮은 것 같아요. 조금 오래 걸리는 작업이기는한데

[thdwoqor]

ㅇㅇ 우리보다 새로들어오신분들한테 더 도움이 많이될꺼같아서