[🚀 사이클2 - 미션 (블랙잭 베팅)] 루디 미션 제출합니다.

.github/pull_request_template.md

@@ -12,24 +12,6 @@
 - [ ] 미션의 필수 요구사항을 모두 구현했나요?
 - [ ] Gradle `test`를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
 - [ ] 애플리케이션이 정상적으로 실행되나요?
-- [ ] [프롤로그](https://prolog.techcourse.co.kr)에 셀프 체크를 작성했나요?
-  - <!-- 작성한 셀프 체크의 링크를 남겨주세요. -->
-
-
-## 객체지향 생활체조 요구사항을 얼마나 잘 충족했다고 생각하시나요?
-
-### 1~5점 중에서 선택해주세요.
-
-- [ ] 1 (전혀 충족하지 못함)
-- [ ] 2
-- [ ] 3 (보통)
-- [ ] 4
-- [ ] 5 (완벽하게 충족)
-
-### 선택한 점수의 이유를 적어주세요.
-
-<!-- 이유 작성 -->
-
 
 ## 어떤 부분에 집중하여 리뷰해야 할까요?
 

README.md

@@ -2,66 +2,302 @@
 
 블랙잭 미션 저장소
 
-## 구현할 기능 목록
+---
+
+# 사이클1 구현 기능
+
+## 1. 카드 덱 생성 및 셔플
 
-### 카드 덱 생성 + 셔플
 - [x] 52장의 카드를 생성한다.
-- [x] 카드는 무늬별 숫자순으로 생성된다.
-- [x] 카드를 셔플한다.
+- [x] 카드는 무늬별 숫자 순서로 생성한다.
+- [x] 생성된 카드를 셔플한다.
 
-### 플레이어/딜러 관리
-- [x] 플레이어를 플레이어 목록에 등록한다.
-- [x] 딜러를 만든다.
-- [x] 카드를 돌린다.
+---
 
-### 카드 점수 계산
-- [x] J,Q,K는 10으로 처리한다.
-- [x] Ace는 1점으로 처리한다.
+## 2. 플레이어 및 딜러 관리
+
+- [x] 플레이어를 생성한다.
+- [x] 플레이어 목록에 등록한다.
+- [x] 딜러를 생성한다.
+- [x] 플레이어와 딜러에게 카드를 분배한다.
+
+---
+
+## 3. 카드 점수 계산
+
+- [x] 카드 숫자를 기본 점수로 사용한다.
+- [x] Jack, Queen, King은 10점으로 처리한다.
+- [x] Ace는 기본적으로 1점으로 처리한다.
 - [x] 카드 점수를 합산한다.
 
-### Ace 1/11 처리
-- [x] 현재 합산 점수에 10점의 여유가 있으면 10점을 더한다.
+---
+
+## 4. Ace 점수 처리 (1 / 11)
+
+- [x] 현재 점수에서 10점을 추가해도 21을 넘지 않는 경우 Ace를 11로 계산한다.
+
+---
+
+## 5. 버스트 판정
 
-### 버스트 판정
-- [x] 21점이 넘으면 버스트
+- [x] 카드 합이 21을 초과하면 버스트로 판정한다.
+
+---
 
-### 히트/스탠드 입력
-- [x] 버스트가 아니면 히트/스탠드를 입력받는다.
-- [x] 히트면 카드를 한 장 더 받는다.
-- [x] 스탠드면 턴을 종료한다.
+## 6. 히트 / 스탠드 진행
+
+- [x] 버스트가 아닌 경우 히트/스탠드 입력을 받는다.
+- [x] 히트를 선택하면 카드를 한 장 더 받는다.
+- [x] 스탠드를 선택하면 해당 플레이어의 턴을 종료한다.
+
+---
 
-### 승패 판정
-- [x] 딜러와 점수를 비교한다.
-- [x] 결과를 생성한다.
+## 7. 승패 판정
 
-### 결과 출력
+- [x] 딜러와 플레이어의 점수를 비교한다.
+- [x] 게임 결과(승/무/패)를 생성한다.
 
 ---
 
-### TO-DO
-- [x] Enum 출력값 변경
-  - [x] 승패 출력값 변경
-  - [x] domain.card.Suit 출력값 변경
+## 8. 결과 출력
+
+- [x] 플레이어 및 딜러의 카드와 점수를 출력한다.
+- [x] 게임 결과를 출력한다.
+
+---
+
+# 사이클1 리팩터링 및 개선 작업
+
+## 출력 및 표현 개선
+
+- [x] Enum 출력값 수정
+  - [x] 승패 결과 출력값 변경
+  - [x] `domain.card.Suit` 출력값 변경
+- [x] Ace, Jack, Queen, King이 숫자 값으로 출력되는 문제 수정
+
+---
+
+## 게임 로직 수정
+
 - [x] 딜러 승패 판정 오류 수정
-- [x] 버스트인데 hit/stand 질문
-- [x] Ace, Jack, Queen, King 이름이 값(1,10)으로 출력되는 문제
-- [x] domain.game.GameManager 리팩터링
-- [x] 패키지 정리
-- [x] drawDealerCard() 메서드의 응답값 미사용
-- [x] GameManager의 책임 재분배 
-  - [x] Deck 초기화, 셔플 책임 제거
-  - [x] DTO 생성 책임 분리
-  - [x] 승패 판정 책임 분리
-- [x] GameController 구조 수정
-- [x] 디미터의 법칙 
-  - [x] 스트림 체이닝은 줄바꿈해서 작성
-  - [x] 체이닝 메서드 안생기도록 구조 수정
-- [x] rank 1 보다는 의미있는 값 (`ACE`)가 이해하기 쉽다
-- [x] 주석이 정말 필요한지, 이름이나 구조로 충분하지 않은지
-- [x] primitive 타입 wrapper로 감싸기
-- [x] 일급 컬렉션 -> Hand로 수정
-  - [x] 핸드 기능 추가(스코어 계산, 상태값 판단, ACE 계산 로직) 및 기존 Calculator 제거
-- [x] mutable이어야 할 이유가 없다면, 반드시 final을 붙일 것
-- [x] 플레이어가 입력되지 않는 경우에 대한 예외처리
-- [x] 규칙 적용
+- [x] 버스트 상태에서도 hit/stand 질문이 나오는 문제 수정
+
+---
+
+## 구조 리팩터링
+
+- [x] `GameManager` 리팩터링
+- [x] `GameController` 구조 수정
+- [x] 패키지 구조 정리
+
+### GameManager 책임 재분배
+
+- [x] Deck 초기화 및 셔플 책임 제거
+- [x] DTO 생성 책임 분리
+- [x] 승패 판정 책임 분리
+
+---
+
+## 코드 스타일 및 설계 개선
+
+- [x] 디미터의 법칙 적용
+  - [x] 스트림 체이닝 시 줄바꿈 적용
+  - [x] 과도한 체이닝 메서드 제거
+- [x] 의미 있는 상수 사용 (`1` → `ACE`)
+- [x] 불필요한 주석 제거 (이름/구조로 표현)
+- [x] primitive 타입을 wrapper 객체로 감싸기
+- [x] mutable일 필요가 없는 경우 `final` 사용
+
+---
+
+## 도메인 구조 개선
+
+- [x] 일급 컬렉션 적용 → `Hand`
+- [x] `Hand`에 기능 통합
+  - [x] 스코어 계산
+  - [x] 상태 판단
+  - [x] Ace 계산 로직
+- [x] 기존 `Calculator` 제거
+
+---
+
+## 예외 처리 및 테스트
+
+- [x] 플레이어 입력이 없는 경우 예외 처리
+- [x] 게임 규칙 검증 로직 추가
 - [x] 테스트 케이스 추가
+
+
+---
+
+# 사이클2 기능 구현
+
+## 1. 배팅 금액 관리
+- [X] 배팅 금액을 관리하는 도메인을 구현한다.
+  - [X] 처음 받은 배팅 금액을 저장
+  - [X] 입력 받은 정산 시 결과 상태(승/무/패/블랙잭/버스트)에 따라 계산한 총 수익을 리턴
+  - [X] 딜러를 플레이어의 상속을 받지 않고, 딜러와 플레이어 모두 추상화 시키는 Participants 생성
+## 2. 판정 추가
+- [X] 기존 `Result`에 블랙잭과 버스트를 추가
+- [X] 처음 BlackJack이 뜬 경우 블랙잭 상태로 결과에 저장
+  - 기존에는 상태값을 저장해두지 않고 마지막에 핸드 결과로 최종 Dto 리스트를 만들어 승패판정을 하였으나, 수정된 상황에서 블랙잭을 미리 체크하고 히트/스탠드 및 승패 판정에서 제외해야 하므로 새로운 기능 추가
+    - [X] 베팅금액과 결과를 함께 저장하도록 수정
+    - [X] 초기 카드 드로우가 끝난 직후 블랙잭인 유저를 찾아서 결과 필드 갱신
+- [X] 결과에 따른 배당 수익을 상태 값으로 가지도록
+  - 무승부는 원금 리턴 ->  *1
+  - 승은 원금 + 수익 -> * 2
+  - 패, 버스트는 원금 손실 -> * -1
+  - 처음부터 블랙잭인 경우 배팅의 1.5배 수익 -> * 2.5
+- [X] 플레이어 Hit/Stand 단계에서 BlackJack이 아닌 유저만 필터링하여 문답 진행
+- [X] 딜러 추가 드로우 단계에서 Bust가 되면 즉시 최종 결과 생성 단계로 이동
+  - [X] 각 플레이어에 대해 최종 Result를 계산
+    - [X] 플레이어가 bust면 BUST
+    - [X] bust가 아니면 딜러와 점수 비교 후 WIN, LOSE, DRAW 판정
+    - [X] natural blackjack인 경우 블랙잭 배당 규칙을 반영할 수 있도록 별도 처리 
+  - [X] 계산된 Result 바탕으로 정산 금액 계산
+  - [X] Result와 정산 금액을 포함한 DTO 생성
+
+## 3. 배팅 금액 입력하여 플레이어 생성
+- [X] 플레이어 이름 입력 후 배팅 금액도 입력
+- [X] 플레이어와 금액을 매핑해서 플레이어 생성
+- [X] 플레이어의 배팅 금액을 다루는 메서드 구현
+
+## 4. 베팅 결과 판정 및 출력
+- [X] 기존 딜러의 승,무,패 출력 기능 제거
+- [X] 플레이어들의 승, 무, 패(버스트), 블랙잭 기준으로 값을 계산하여 수익을 출력하도록 수정
+- [X] 딜러 기준 총 수익 계산 받아서 출력하는 기능 구현
+
+
+## 고민
+- Players를 copyOf로 해도 얕은 복사라 Player 자체에는 접근이 가능해진다. Player 자체의 변동 가능성은?
+
+
+---
+
+## PR 리뷰 후 추가 수정 사항
+- [X] 사용하지 않는 Result enum 필드 제거
+- [X] DTO의 intialHandSize 제거
+- [X] 동일한 카드가 플레이어에게 드로우되는 문제 해결
+- [X] Players 인스턴스 생성 및 추가 방식 수정
+- [X] splitPlayerNameInput 스트림 불변 리스트로 수정(toList)
+- [X] 테스트에서만 쓰이는 handSize 메서드 제거
+- [X] GameResultJudge의 결과 분기 책임을 enum에게 넘기기
+~~- [ ] 컨트롤러가 매니저를 상태로 들고있는 구조 개선~~
+- [X] Result와 배당 수익금 비율 분리
+- [X] PlayerStatus에서 수익 계산 하는 부분 분리하기
+- [X] 기록 내용 README.md 추가
+- [X] updateNaturalBlackJack 상태 업데이트가 밖에서 호출되는 문제 수정
+
+
+
+
+## 📝 미션 기록
+
+### 기능 추가로 인해 수정한 위치
+
+이번 미션에서는 **베팅 기능을 추가한다고 가정하고 변경 범위를 분석**하였다.
+
+베팅 기능은 단순한 내부 로직이 아니라  
+**입력 → 상태 저장 → 게임 진행 → 결과 계산 → 출력** 전체 흐름에 영향을 주는 기능이었다.
+
+그 결과 다음 위치에서 수정이 필요하다고 판단하였다.
+
+| 수정 위치 | 이유 |
+|---|---|
+| Player | 플레이어가 베팅 금액을 상태로 가져야 한다 |
+| Players | 플레이어 집합에서 베팅 정보와 결과 집계가 필요 |
+| GameManager | 게임 결과 계산 시 베팅 정산 로직 추가 |
+| GameController | 게임 시작 전에 베팅 금액 입력 필요 |
+| InputView | 플레이어별 베팅 금액 입력 |
+| OutputView | 베팅 결과 및 수익 출력 |
+| GameFinalResultDto | 결과 DTO에 수익 정보 추가 |
+| Result | 승패에 따른 정산 기준 추가 |
+
+**총 수정 위치: 8개**
+
+이를 통해 **하나의 기능이 여러 계층을 따라 이동하면 수정 범위가 넓어진다**는 것을 확인했다.
+
+---
+
+### 사이클 1 대비 수정 범위
+
+사이클1에서는 게임 로직 대부분이 `GameManager`에 집중되어 있었다.
+
+```
+GameManager
+ ├ 카드 분배
+ ├ 점수 계산
+ ├ 게임 진행
+ └ 승패 계산
+```
+
+이 구조에서는 기능이 추가될 때 **GameManager에 수정이 집중되는 문제**가 있었다.
+
+이번 사이클에서는 다음과 같이 책임을 분리하였다.
+
+- `Hand` → 카드 점수 계산
+- `Players` → 플레이어 집합 관리
+- `GameResultJudge` → 승패 판정
+- `PlayerStatus` → 플레이어 상태 관리
+
+그 결과 **기능 추가 시 수정 범위가 특정 객체에 집중되지 않고 분산되도록 개선되었다.**
+
+---
+
+### 규칙 적용으로 변경한 코드
+
+팀에서 다음과 같은 규칙을 정하였다.
+
+- 책임 분리 기준
+    - **(If-Then)** 만약 특정 요구사항이 변경되었을 때, 그와 무관한 코드들까지 한 클래스 안에서 함께 수정하거나 테스트해야 한다면 → 변경의 원인이 하나가 되도록 책임을 분리하여 응집도를 높인다.
+    - **(기준)** 변경의 이유가 하나 이상일 때 분리한다.
+- 변경 범위 제한 규칙
+    - **(If-Then)** 만약 기능 추가 시 3곳 이상의 파일 수정이 필요하면 → 공통 로직을 추출하거나 책임을 재분배한다
+    - **(기준)**  책임을 적절히 캡슐화하지 못해, 단일 변경의 파급 효과가 여러 객체(3곳 이상)로 흩어질 때 변경 범위를 제한한다.
+- 테스트와 설계의 관계 규칙
+    - **(If-Then)** 만약 비교와 같은 연산을 위해 해당 데이터를 가진 객체의 데이터를 직접 꺼내와서 사용하고 있다면 → 데이터를 가진 객체에게 직접 물어보도록(Tell, Don't Ask) 수정하여 변경 여파를 내부에 가둔다.
+    - **(기준)** 외부에서 객체의 데이터를 직접 꺼내어 연산이나 판단을 수행하는 경우, 데이터를 가진 객체에게 직접 물어보도록 변경한다.
+
+모든 규칙을 항상 의식하면서 작업하진 못하였지만, 대표적으로 아래의 규칙을 가장 의식하면서 작업했다.
+
+> **Tell, Don't Ask**
+>
+> 객체의 데이터를 꺼내와 외부에서 판단하지 말고  
+> 해당 객체에게 직접 물어보도록 한다.
+
+이 규칙을 적용하면서, 기존에 도메인 객체의 필드 값을 외부에 호출하여 사용하던 방식에서
+도메인 객체 스스로 행동하여 상태 값을 활용한 책임을 지도록 하였고 외부에서는 내부 구현을 몰라도
+요청만으로 원하는 값을 얻을 수 있도록 하였다.
+
+이를 통해 응집도가 감소하고, 객체 간의 협력 관계를 기존보다 개선된 형태로 구축할 수 있었다고 생각한다.
+
+---
+
+### 테스트가 설계를 도운 순간
+
+딜러의 최종 수익을 계산하는 테스트를 작성하면서  
+딜러 수익을 별도의 규칙으로 다시 계산하기보다  
+**플레이어 수익의 합에 음수를 취한 값으로 정의하는 구조**가 더 자연스럽다는 점을 확인했다.
+
+```java
+assertThat(firstPlayerResult.getProceeds()).isEqualTo(1000);
+assertThat(secondPlayerResult.getProceeds()).isEqualTo(-2000);
+assertThat(dealerResult.getProceeds()).isEqualTo(1000);
+```
+이 테스트를 통해
+딜러와 플레이어의 정산 로직을 각각 따로 두기보다
+플레이어 결과를 먼저 계산한 뒤 딜러 결과를 합산으로 구하는 것이
+규칙 중복을 줄이고 설계를 더 단순하게 만든다는 점을 알 수 있었다.
+
+---
+
+### 이번 미션에서 얻은 인사이트
+
+기능 추가 자체보다 더 크게 느낀 점은 다음이다.
+
+- 역할이 명확한 객체 (`Card`, `Hand`, `Deck`) 는 변화에 강하다.
+- 여러 책임이 섞인 객체 (`GameManager`) 는 변화에 약하다.
+- 테스트를 작성하면서 설계에서 불안정한 지점이 어디인지 파악할 수 있다.
+
+이번 미션을 통해 구조에 대한 설계가 잘못 되었는지 알아챌 수 있는 신호에는 무엇이 있고,
+어떤 설계가 유연하면서도 안정적인 코드를 작성할 수 있는지 알 수 있었다.