한결과 레지아이스

42GG 백엔드 시퀀스 다이어그램 2부입니다. 이번 글은 정보 전달이라기보다는 기록에 의미를 두고 작성하게 되었습니다. 백엔드에서 사용한 컨트롤러가 이것뿐이지는 않지만, 구현할 때 애를 먹거나 단순 조회가 아니고 무언가 로직이 들어간 부분들에 대해서 정리해 보았습니다. 개인적으로는 로직도 중요하지만 어떤 예외 처리를 어떤 이유로 했는지도 꽤나 많이 배우게 된 부분입니다. 로직을 만드는 것은 누구나 고생한다면(혹은 하지 않아도) 만들 수 있지만, 서비스로서 원활히 돌아가게 하기 위해선 수많은 예외 상황들을 생각하고 이에 대해 적절한 처리를 해줘야 한다고 느꼈습니다. 사실 저희 서비스에서 로직은 어려운 부분도 아니고 누구나 비슷하거나 어쩌면 다른 더 나은 방식으로도 비슷한 결과를 낳도록 구현하는게 어렵지 않..

기존의 42GG DB 설계를 박정규 멘토님께 조언을 구해 수정했습니다. 원래는 어땠고, 우리끼리 어떻게 고민했으며, 결국 어떻게 바꿀 지에 대해 적었습니다. 0. DB 설계도 변천사 a. 기존 설계 b. 멘토링 이후 기존 설계에 관계성 추가 c. 매핑 테이블을 이용해 수정한 결과 42GG 서비스는 처음에 어떤 종류의 게임이든, 팀이 몇 개 존재하든, 각 팀에 몇 유저가 존재하든 상관없이 대전 서비스를 제공할 수 있도록 확장성을 염두에 두고 설계를 했다. 이 과정에서 어려움을 겪어 기존의 형태로 설계했는데, 먼저 어떤 시행착오를 겪었는지 설명해보려고 한다. 1. 태초의 설계 DB설계를 처음 해봤고, 팀원들도 함께 미숙하던 시절이라 최대한 확장성을 염두에 두고 만드려면 어떻게 해야 할까 고민을 많이 했다. ..