Continuous Challenge

주요 기능 분석1. 포인트 충전사용자가 자신의 계정에 포인트를 충전. 충전 금액이 포인트 잔액에 추가됨.단일 계정 기준으로 충전이 수행 되므로 충돌 가능성 낮음.충전 요청이 동시에 발생할 가능성은 상대적으로 낮으며, 발생하더라도 포인트는 독립적으로 누적 처리2. 결제 시 포인트 차감사용자가 결제 시 포인트 차감. 잔액 부족 시 차감 불가.단일 계정 기준으로 차감이 수행되므로 충돌 가능성 낮음.3. 주문 시 상품 재고 차감주문 시 선택한 상품의 재고를 차감. 재고 부족 시 차감 불가.동일 상품에 대한 다수의 주문 요청이 동시에 발생할 가능성 높음.4. 선착순 쿠폰 발급쿠폰 발급 시 쿠폰의 잔여수량을 차감하고 사용자에게 쿠폰을 발급함.다수의 사용자가 동시에 요청하여 쿠폰 초과 발급 가능성이 매우 높음.동시성..

4주차가 기능 구현이었다면, 5주차는 4주차에 구현한 코드를 고도화하는 것 이었다. ㅇ 4주차에 구현하지 못한 기능들 구현하기  - 잔액 히스토리 남기기  - 결제 완료 시 주문 상태 업데이트 하기  - 아키텍처에 맞게 파일 다시 정리하기 (DataPlatformService 이동, application -> infrastructure) ㅇ Filter 로 Logging 처리하기ㅇ Interceptor 로 사용자 검증하기ㅇ ExceptionHandler 로 예외 처리하기 ㅇ 동시성 통합 테스트 보완하기 이번 주차에는 3군데에서 동시성 제어에 대한 처리를 했다.1. 잔액 사용2. 재고 차감3. (선착순) 쿠폰 발급모두 비관적 락을 사용해서 처리를 하였다. 앞으로는 지금까지 구현한 코드를 기반으로 계속해서 ..

이번 4주차는 가장 힘들었던 주라고 감히 말해본다...왜 2주차랑 비슷할 거라고 생각했지..? 하지만.. 해내고 말아..점점 나이를 한 살 두 살 먹어가며 대학생 때처럼 다음 날 시험이 있다고 밤새는 것이 당연하지 않아졌다.오히려 다음 날 중요한 일정이 있을 때에는 충분한 수면을 취하는 것이 좋은 컨디션을 만든다는 것을 알았기 때문에...그렇게 지내왔던 나를 새벽까지 깨어있게 만든 것이 바로 항해...내가 새벽 4시 넘어서까지 깨어있을 수 있는 사람인지 몰랐는데 이번에 항해 덕분에 알게 되었다.나도 밤샐 수 있는 사람이었구나... ㅇ0ㅇ일요일인 오늘까지도 밤샘의 여파가 남아있는 것 같다... 오늘은 푹 자야지... 4주차에는 3주차에 했던 이커머스 서비스 설계를 바탕으로 코드를 구현하는 작업을 했다. +..

3주차부터 5주차까지는 이전 과제보다는 긴 호흡으로 서버를 구축하는 과제를 진행한다. 3주차는 설계 단계로 프로젝트의 시작인 마일스톤 작성하기, 도메인 간의 흐름을 시간순으로 나타내는 시퀀스 다이어그램 작성하기, ERD 설계하기, API 명세서와 MockAPI 작성하기를 진행했다.코딩이 없어서 조금 편하겠구나 라고 생각했는데 그렇지 않았다...설계한 내용을 다음주에 코딩으로 구현한다고 생각을 하니 이걸 어떻게 코드로 구현할지를 머릿속으로 구상하면서 설계를 진행해야했고, 많은 시간을 나의 머릿속의 생각들과,,, 싸워야,,, 했다,,,(이렇게 깊은 생각을 해본 게 얼마만이던가,,,ㅜ) 마일스톤 마일스톤은 Github에 Project를 이용하여 작성하였다. 이번 과제를 진행하면서 새롭게 알게 된 깃허브의 기..

1주차 과제의 미션이 멀티 스레드 환경에서의 동시성 이슈를 해결하는 것이었다면, 2주차 과제의 미션은 멀티 인스턴스 환경에서의 동시성 이슈를 해결하는 것이었다. (DB는 MySQL 또는 MariaDB 사용하기,,)멀티 인스턴스 환경에서 동시성 이슈를 해결하기 위한 방법 중 하나는 DB 레벨에서 Lock을 사용하는 것이다. MariaDB의 트랜잭션 격리수준(transaction isolation) 기본은 "REPEATABLE READ"이다. 트랜잭션 격리수준(Isolation Level)1. Read Uncommitted (Level 0) 어떤 트랜잭션의 내용이 커밋이나 롤백과 상관없이 다른 트랜잭션에서 조회가 가능하다. 정합성의 문제가 많은 격리 수준으로 RDBMS 표준에서는 격리수준으로 인정하지 않는다..

클린 아키텍처2주차 과제의 핵심 키워드는 아키텍처 였다. 클린 코드, 클린 아키텍처, 클린 코더의 저자, Robert C Martin은 대부분의 아키텍처는 세부적인 차이는 있어도 공통적인 목표는 계층을 분리하여 관심사의 분리하는 것이라고 말하는데, 이런 아키텍처가 동작하기 위해서는 의존성 규칙을 지켜야 한다고 한다.의존성 규칙이란?모든 소스코드 의존성은 반드시 외부에서 내부로, 저수준에서 고수준 정책을 향해야 한다.  레이어드 아키텍처아직까지 많은 회사에서 사용하는 아키텍처 구조는 레이어드 아키텍처 일 것이다.하지만 레이어드 아키텍처에서는 고수준 정책(Service)이 저수준 정책(DB의 구현체)을 직접 참조하게 되고 이는 위에서 언급한 의존성 규칙을 위반한다. 우리는 이것을 DIP(의존성 역전의 원칙,..

TDDTDD는 현업에서 사용하지는 않지만 이전에 NEXTSTEP 교육을 통해 학습했던 경험이 있어서 그렇게 부담으로 다가오진 않았다.그리고 1주차 과제에서 요구하는 것은 '테스트 코드를 먼저 작성하는 TFD 방식 보다는 테스트 코드 자체에 대한 중요성을 강조하여 기능을 구현한 뒤 테스트 코드를 작성하는 TLD 방식으로 코드를 작성해도 된다. 오히려 TFD로 작성하는 경우를 본 적이 드물다.' 고 말씀해 주셔서 조금은 편하게 과제를 진행할 수 있었다. 이번 과제에서는 요구 사항 분석과 정책 설정(최대 금액 등)에 신경 썼다.구현해야 할 기능, 예외 처리해야 할 부분을 먼저 구성하고 나서 구현을 시작했다.1주차 과제의 요구사항은 크게 포인트 조회, 충전, 사용, 히스토리 내역 조회 기능을 구현하고 테스트 코..

태그를 추가하여 해당 프로젝트의 springboot 버전을 넣어주었더니 오류가 해결되었다.

스레드 상태 1. 스레드 객체를 생성(NEW)하고, start() 메소드를 호출하면 실행 대기 상태(RUNNABLE)가 된다. 2. 실행을 대기하는 스레드는 CPU 스케쥴링에 따라 CPU를 점유하고 run() 메소드를 실행한다. 이 때를 실행(RUNNING) 상태라고 한다. 3. 실행 스레드는 run() 메소드를 모두 실행하기 전에 스케줄링에 의해 다시 실행 대기 상태로 돌아갈 수 있다. 이렇게 스레드는 실행 대기 상태와 실행 상태를 번갈아 가면서 자신의 run() 메소드를 조금씩 실행한다. 4. 실행 상태에서 run() 메소드가 종료되면 더 이상 실행할 코드가 없기 때문에 스레드의 실행은 멈추게 된다. 이를 종료 상태(TERMINATED)라고 한다. 실행 상태에서 일시 정지 상태로 가기도 하는데, 일시..

작업 스레드 생성과 실행 멀티 스레드로 실행하는 프로그램을 개발하려면 몇 개의 작업을 병렬로 실행할지 결정하고 각 작업별로 스레드를 생성해야 한다. 자바 프로그램은 메인 스레드가 반드시 존재하기 때문에 메인 작업 이외에 추가적인 작업 수만큼 스레드를 생성하면 된다. 자바는 작업 스레드도 객체로 관리하므로 클래스가 필요하다. Thread 클래스로 직접 객체를 생성해도 되지만, 하위 클래스를 만들어 생성할 수도 있다. Thread 클래스로 직접 생성 Thread thread = new Thread(Runnable target); java.lang 패키지에 있는 Thread 클래스로부터 작업 스레드 객체를 직접 생성하려면 다음과 같이 Runnable 구현 객체를 매개값으로 갖는 생성자를 호출하면 된다. Run..