9주차 책임 분리를 통한 애플리케이션 설계 1. 문제비즈니스 로직과 트랜잭션 범위 고려@Transactionalvoid payment() { 결제_요청_검증() 유저_포인트_차감() 결제_정보_저장() 주문_정보_전달() //외부 플랫폼 API 호출 } 예를 들어서 상품을 결제하는 결제 함수가 있다.결제처리 하는 비즈니스 로직 안에 여러 가지 함수들이 존재하며, 결제 처리가 끝난 후 최종적으로 주문 정보를 외부 API를 호출하여 전송해 주는 기능까지 존재한다. 즉, payment()가 정상적으로 성공 처리 되기 위해서는 외부 API에 호출 또한 정상적으로 통신이 되어야 한다. 위에 로직은 정상적인 것 같지만 심각한 문제가 있다.- 외부 플랫폼 API 호출 시 네트워크 이슈로 ..

이번 주차는 콘서트 프로젝트를 진행하면서 대기열을 기존에는 RDB를 사용하여 구성하였으면, REDIS를 사용해서 구현하기 위해 다시 설계하고 구현해 보는 시간을 가졌다.대기열 리팩토링대기열은 기존에 동시성 유즈 케이스 고민하면서 사용했던 Redisson 라이브러리를 활용해서 Redis를 사용했다.대기열은 두 가지 상태를 가지고 있으며, 서비스 이용을 위해 대기하거나, 서비스를 이용할 수 있고, 대기열 만료 시간이 지난 사용자는 대기열에서 삭제가 되기 때문에 별도의 상태를 관리하지 않는 구조로 설계 방향을 잡았다.Wating QueueredissonClient.getScoredSortedSet("waitQueue");Redis Sorted Set 자료 구조를 기반으로 만들어진 RScoredSortedSet..

벌써 항해 플러스 과정이 절반이 지났다. 5주 차 동안 TTD, 아키텍처, 서버구축 등 과제를 하면서 정신없이 달려왔다. (절반 이상의 시간이 그동안 배운 내용들에 대해서 정리해야 될 것 같다.) 이번 주차 발제 과제였던 콘서트 프로젝트를 진행하면서 필요한 도메인이 무엇인지 생각하고 도메인 중심적으로 개발을 진행하려고 했지만, 막상 개발을 하면서 데이터를 우선 적으로 가지고 와야 할 것 같은데?라는 느낌이 강하게 들어서 개발을 진행하고 돌이켜보니 서비스 코드에 비즈니스 로직이 다 들어가는 느낌 적인 느낌.. DDD에 대해서 조금이라도 감을 잡기 위해서 "도메인 주도 개발 시작하기 : DDD 핵심 개념 정리부터 구현까지 " 책을 구매해서 읽어보고 있는데 (현재 3장..) 내가 한건 도메인 주도 개발 이라기..

4주차 과제를 진행하면서 생긴 고민 콘서트 예약 프로젝트를 선정하고, 대기열 시스템을 구현하며 동시성 테스트를 작성했는데 통과하지 못하고 있다. 대기열 구현을 잘못한 것 같아서 지금 어떻게 해결해야 할지 고민하고 있다. 동시성 테스트 시나리오는 2가지로 구성 1. 여러 명의 사용자가 동시에 신청하는 경우 -> QUEUE_LIMIT 가 50인 경우, 100명의 사용자가 신청이 들어와도 50명의 사용자만 ONGOING 상태로 들어와야 한다. 2. 한 명의 사용자가 여러 번 신청하는 경우 -> QUEUE 테이블에 한 번만 들어와야 한다. 1. 여러 명의 사용자가 동시에 신청하는 경우 이 시나리오는 ONGOING 상태의 카운트를 QueueService가 init 되는 시점에 OngoingCount를 가지고 와서..

3주차 발제 서버구축 발제 주제를 보자마자 지금 까지는 장난이었고, 본게임이 시작되는 것 같은 느낌이었다. e-커머스 서비스, 맛집 검색 서비스, 콘서트 예약 서비스 3가지 시나리오 중 본인이 원하는 시나리오를 선택하여 프로젝트를 2주 동안 진행하게 되며, 5주 차부터 시작될 대용량 서비스 주제도 이번 프로젝트를 기반으로 리팩토링 하면서 진행하는 것 같다. 우선 나는 프로젝트 주제를 보자마자 콘서트 예약 서비스를 하고 싶었다. 코치님들이 난이도로 치면 제일 어렵다고 하셨다. 많은 걸 얻으려고 시작했기 때문에 어려운 만큼 더 많은걸 얻을 수 있지 않을까?라는 생각도 있었고 사실 평소에 친구들의 티켓팅을 자주 도와주었던 기억들이 있어서 어떻게 동작할까?라는 호기심이 컸다. 이번 주차 과제는 코딩은 없지만, ..

2주차 발제 주제는 아키텍처로 나에겐 정말 낯선 주제였다. 그동안 개발을 진행해 오면서 사실 아키텍처 부분에 있어서 심도 있게 고민해 본 적이 없었던 것 같다. 웹 개발을 조금이라도 배워봤으면 모두 다 알고 있는 레이어드 아키텍처 인생을 살고 있었기 때문에 당연하다는 듯이 레이어드 아키텍처를 사용해 왔다. 클린 아키텍처, 헥사고날 아키텍처는 얼핏 들어보기는 했지만 엄청난 패키지 구조를 보고 쉽게 이해하지 못했었다. (클린 아키텍처와 헥사고날 아키텍처의 차이점이 사실 아직 좀 애매한 것 같다.) 이번 주차 과제는 클린 + 레이어드 혹은 원하는 아키텍처를 선택하여 수강신청 API 를 구현하는 과제로 진행되었으며 과제를 진행하면서 정말 엄청난 일들을 경험했다. 우선 과제를 진행하기에 앞서서 이번 기회에 클린 ..

항해 플러스 1주차 회고 원래는 저번주에 작성했어야 하는 1주차 회고지만.. 2주차 과제를 받고 나서 2주차 과제를 해결하기 위해 나름(?) 공부를 진행하여 2주차 과제 풀이에 우선적으로 집중하느라 이제야 작성한다. 1주차 과제는 TDD 기반으로 진행하는 간단한 포인트 충전, 사용 API 과제였다. (HashMap으로 구성된 DB 구조) TDD기반 개발 경험이 없는 나는 과제 시작 전에 급하게 '테스트 주도 개발 시작하기 - 최범균', '테스트 주도 개발 - 켄트 벡' 책을 빠르게 읽고서 1주차 과제를 진행했다. (정말 다행이라고 생각) 사실 개발을 하면서 단위 테스트 와 통합 테스트의 차이를 잘 이해하지 못했다. (1차 멘토링을 받기 전까지 @SpringBootTest를 사용해서 통합 테스트만 만들었다..

내가 개발자’를 해야겠다고 생각한 이유는 단순했다. 내가 학습해서 지식을 얻는 만큼 내 몸값이 올라가고, 그 자체만으로도 남들에게 인정받을 수 있다는 점이 매력적으로 느껴졌다. 정말 열심히 공부해서 남들에게 인정받을 만한 개발자가 되어야지라고 생각했다. 취업을 하기 위해 국비 학원 수료 후 공부를 하면서 솔루션 회사에 취업하게 되었다. 취업하고 나서도 열심히 공부해서 더 높이 올라갈 거라고 다짐했다. 취업 후 내가 생각했던 내 모습과는 전혀 달랐다. 현실 속 나는 180도 다른 모습으로 취업한 후 스스로에게 업무 핑계를 대며 공부를 멀리했다. 회사에서 하는 업무만으로는 기술적인 한계가 있었기에 나의 성장 속도는 멈추었다. 나는 이렇게 생각했었다. “개발자로 취업해서 일을 하게 되면 자연스럽게 내 기술 향..