[🚀 사이클2 - 미션 (블랙잭 게임 실행)] 아티 미션 제출합니다. by ParkJiYeoung8297 · Pull Request #1113 · woowacourse/java-blackjack

ParkJiYeoung8297 · 2026-03-13T18:10:21Z

사이클 2

기능

배팅 금액 입출력 기능 구현
전체 배팅 금액 구하는 기능 추가
최종 수익 출력하는 기능 구현
배팅 금액 예외 시 재입력 기능 추가
플레이어 burst면 상금 잃는 기능 추가
딜러 수익 계산 금액 기능 구현

사이클1 피드백 반영

Player의 필드 List를 일급컬렉션 Cards로 변경
기존 Cards는 전체 카드를 의미해서 Player에서 사용 못했습니다.
이번 수정 과정에서 전체 카드는 Deck이라는 도메인을 추가하고, Cards는 Player가 들고있는 카드 뭉치로 사용했습니다.
Dealer와 Player의 상속 관계를 제거
Dealer와 Player의 상속 관계로 인해 Dealer가 몰라도 되는 Player의 행동을 상속받고 있었습니다.
이를 해결하고자 Player와 겹치는 행동은 Player에서 처리하고, 딜러의 규칙은 곧 게임의 규칙이기에 Game에서 처리하도록 변경했습니다.
도메인에서 DTO 직접 생성했던 것을 Service에게 책임 이동
Controller에서 출력하는 책임을 OutputView로 이동
하드 코딩 상수화
사용하지 않는 import 정리

To 리뷰어

1.Dealer - Player
딜러의 행동(ex. 자신이 가진 카드의 합 구하기)은 Player와 중복이고,
딜러의 규칙(ex. 16이하이면 카드를 추가로 받는다.)은 게임의 규칙이기에 Game에서 처리할 수 있다고 생각했습니다.
객체에서의 책임은 현실세계와 차이가 있어서, 꼭 딜러가 하는 행동이라고 Dealer에 있어야하는 것이 아니라 응집도를 고려해 다른 곳에 위치할 수 있다고 생각하는데, 이런 구조로 구현하는 것에 대해 피드백 받고 싶습니다.

(이런 구조 → 코드 중복을 줄이기 위해 Dealer 객체를 없애고, 관련 행동과 규칙을 적절한 클래스에 둔다)

Domain
지금 변경한 도메인 구조가 잘 짜여진 것인지 피드백 받고 싶습니다. 어찌보면 Game이 aggregate root와 같다고 보이는데, 이런 구조가 적절할까요?
테스트 수정
도메인이 대거 수정되니, 테스트 코드도 다시 수정해야하는 상황이 발생했습니다.
본 코드랑 테스트 코드의 의존성이 큰거 같은데, 테스트 코드가 변경에 유연하게끔 작성하는 방법이 있을까요?
코드 수정
이미 사용중인 서비스에서는 이와 같이 도메인을 대거 수정하는 과정이 어려울거 같은데, 대거 수정이 필요할 경우 어떻게 해야하는지 궁금합니다.
(하나를 고치면 여러개가 에러나는 상황이다 보니, 저는 전부 주석해놓고 처음부터 하나씩 주석을 해제하고 문제해결하는 방식으로 리팩토링했습니다.)

*피드백을 반영하는 과정에서 도메인 재구성이 필요하다고 생각했습니다. 그래서 리팩토링 과정에서 많은 파일이 바뀌었습니다.🥲
*깃을 제대로 못 만져서, 사이클 1의 커밋 내용도 전부 뜨는 것 같습니다. (보기 힘드실거 같아서 죄송합니다..)
*사이클 1에서 달아주신 리뷰 답글은 14일(토)내로 작성해두겠습니다!

사이클 1의 PR

링크: #956

미션 중 기록

1. 기능 추가로 인해 수정한 위치 개수

기능을 추가하는 과정에서 현재 구조로 확장하기에 어려움이 있었다.
그래서 대부분의 비즈니스 로직을 도메인 안으로 넣어서, 변경에 유연하도록 도메인을 재구성하였다.

1)BlackjackResult삭제
원래는 BlackjackResult에서 승패와 같은 게임의 기록을 저장했는데,
배팅 상금이라는 결과가 하나 더 추가 되면서, 출력 결과(response)를 도메인으로 갖는 것은 확장성이 안좋다고 생각했다.
그래서 BlackjackResult를 없애고, Game이라는 도메인에서 그때그떄 원하는 결과를 반환할 수 있도록 메서드만 구현하였다.

2)Deck 도메인 추가, Cards 일급 컬렉션 수정
Cards라는 일급 컬렉션을 카드 전체(52장)를 타깃으로 사용했다 보니, Player가 갖는 카드 더미는 Cards를 사용하지 못했다.
전체 카드는 랜덤 생성, 카드 추출 기능에 대한 책임만 가지기 때문에 플레이어가 가지는 카드 뭉치 Cards와 따로 분리하는 것이 낫다고 생각했다.
그래서 Player가 소유한 카드 뭉치를 Cards라는 일급 컬렉션으로 사용하기 위해, 전체 카드를 나타내는 Deck이라는 도메인을 추가하였다.
CardGenerator를 파라미터로 받아서 전체 카드 생성에 관해서 Deck에서 처리하도록 하였다.
카드 생성을 저번에 인터페이스로 해서 분리하니 이부분에 대한 수정은 편리했다.
(CardGenerator를 파라미터로 받아서 메서드로만 호출하면 되니까.)

4)Game 도메인 추가, Dealer 도메인 삭제
Game에 대한 비즈니스 로직이나 규칙들이 Player, Dealer, Cards 등에 흩어져있어 테스트 코드 작성에 어려움이 있었다.
따라서, 블랙잭 게임 규칙에 대한 메서드를 모아두기 위해 Game이라는 도메인을 추가하였다.

Game을 추가하고 나니 Dealer의 필드는 Player와 겹치고, Dealer의 규칙은 Game에서 수행할 수 있을 것으로 보았다.
(16이하이면 카드를 더 받는다는 Dealer의 규칙은 게임의 규칙이라고 볼 수도 있기 때문이다.)
Game과 Dealer는 항상 1대 1로 존재하기 떄문에, 객체 생성-소멸 주기가 같다고 판단하여 관련 로직을 Game에 두었다.

추가로 Dealer는 게임을 만들 때 외부에서 주입해주는 방식으로 했다. 그래야 GameTest에서 Dealer의 카드를 조작해줄 수 있기 때문이다.
테스트를 작성하며 의존성을 줄이는 방향으로 개발을 하게 되었다.

2. 사이클1 때보다 수정 범위가 줄었는가/늘었는가

사이클 1에서 단편적인 결과 출력에만 집중해서 도메인을 설계해서 그런지, 기능 추가를 위해 코드 변경이 막막하고 어려웠다.
그래서 도메인을 재구성하였기 때문에, 사이클1 때보다 수정 범위가 훨씬 컸다.
변경된 구조에서는 기능 추가 시 Game에 코드를 추가하면 되기 때문에, 코드 변경이 적을 것으로 예상된다.

3. 규칙 적용으로 변경한 코드 1곳

(If-Then) 하드코딩된 값이 보인다면, → 상수화한다.
도메인으로 로직을 이동하면서, 상수도 적절한 도메인으로 이동해 응집성 있게 수정하였다.

(If-Then) 같은 객체를 다루는 클래스여도 목적이 다르면, → 클래스를 분리한다. (e.g. Cards -> Deck, Hand)
Cards를 Cards(Player 소유 카드), Deck(전체카드)으로 나누어서 리팩토링하였다.

4. 테스트가 설계를 도운 순간 1회

게임 규칙에 대한 테스트를 진행하려고 했는데,
이런 규칙이 Player, Dealer, Cards 등 여러 도메인에 걸쳐서 존재하는 것이 불편했다.
테스트 구현을 통해 도메인의 책임 분리에 대한 재구성 필요 신호를 포착할 수 있어서 설계에 도움이 되었다.

체크 리스트

미션의 필수 요구사항을 모두 구현했나요?
Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
애플리케이션이 정상적으로 실행되나요?

# Conflicts: # src/main/java/controller/BlackjackController.java # src/main/java/domain/BlackjackResult.java # src/main/java/domain/Dealer.java # src/main/java/domain/Player.java # src/main/java/domain/Players.java # src/main/java/service/BlackjackService.java # src/main/java/validator/Validator.java # src/main/java/view/InputView.java # src/main/java/view/OutputView.java # src/test/java/domain/BlackjackResultTest.java

jurlring

아티 안녕하세요 🐰
질문 주신 부분에 대한 생각들과 코멘트 몇가지 남겨두었어요.
시간 괜찮으실 때 확인해주세요~!
즐거운 주말 되세요~~

jurlring · 2026-03-14T12:13:27Z

src/main/java/domain/Game.java

+        // 1. 참가자들이 모두 burst면 딜러가 승리한다.
+        if (players.isAllPlayerBurst()) {
+            return getPlayersAllBurstCase(matchResult);
+        }
+        // 2. 딜러가 burst이면 살아남은 참가자는 우승이다.
+        if (dealer.isBust()) {
+            return getDealerBurstCase(matchResult);
+        }
+        // 3. 딜러가 burst가 아니면, 딜러보다 크면 승, 작으면 패, 같은면 무승부이다.
+        return getGeneralCase(matchResult);


주석에 대해서는 어떻게 생각하시나요~?
좋은 네이밍과 구조를 가진 코드는 주석이 없어도 충분히 이해될 수 있다고 생각합니다 :)

jurlring · 2026-03-14T13:26:52Z

src/main/java/controller/BlackjackController.java

+                () -> {
+                    return inputView.readBettingPrice(name);
+                }


괄호로 묶을 이유가 있을까요~?

jurlring · 2026-03-14T13:36:33Z

src/test/java/domain/GameTest.java

+import testutil.PlayerTestUtil;
+import utils.generator.CardsGenerator;
+
+class GameTest {


도메인이 대거 수정되니, 테스트 코드도 다시 수정해야하는 상황이 발생했습니다.
본 코드랑 테스트 코드의 의존성이 큰거 같은데, 테스트 코드가 변경에 유연하게끔 작성하는 방법이 있을까요?

저는 도메인이 수정되면 테스트 코드도 함께 수정되거나 다시 작성되는 것은 어느 정도 자연스러운 일이라고 생각해요~!
테스트 코드는 왜 짜야할까요? 테스트 코드는 결국 현재 도메인의 동작과 정책을 검증하기 위한 코드이기 때문에, 도메인의 구조나 정책이 변경되면 테스트 역시 그에 맞게 변경되는 것이 맞다고 생각합니다.

테스트를 나누자면 각 도메인에 대한 테스트/좀 더 큰 단위의 흐름을 구성하는 클래스에 대한 테스트가 있을 것 같은데요!
각 도메인에 대한 테스트는 당연히 변경되어야하는게 맞는 것 같고 흐름을 구성하는 클래스에 대한 테스트는 인터페이스에 세부 도메인에 대한 의존을 줄이면 테스트 코드가 변경에 유연하게끔 작성할 수 있어요!

jurlring · 2026-03-14T13:38:48Z

src/main/java/validator/Validator.java

        }
    }

+    static int validateInteger(String input){


접근제한자는 필요 없을까요?

jurlring · 2026-03-14T13:40:10Z

src/test/java/testutil/PlayerTestUtil.java

-        Player player = new Player("AAAA");
+    public static Player createPlayer(String name, List<Card> cards) {
+        Player player = new Player(name);
        cards.forEach(player::add);


stream의 forEach와 for문은 어떤 차이가 있을까요?

jurlring · 2026-03-14T13:44:43Z

src/main/java/domain/Players.java

        return players.stream().allMatch(Player::isBust);
    }

    public Player getPlayer(int index){


테스트에서만 사용되는 메서드로 보여요 😿

jurlring · 2026-03-14T13:47:47Z

src/main/java/domain/Player.java

+    public void betMoney(int money) {
+        bettingScore = money;


플레이어 생성 시점에 bettingScore를 초기화 하는 방법은 없을까요? 그럼 장점은 어떤게 있을까요?

jurlring · 2026-03-14T13:55:45Z

src/main/java/domain/Player.java

+    public MatchCase calculateMatchCase(int dealerTotal) {
+        if (cards.getFinalScore() > dealerTotal) {
+            return MatchCase.WIN;
+        }
+        if (cards.getFinalScore() == dealerTotal) {
+            return MatchCase.DRAW;
+        }
+        if (cards.getFinalScore() < dealerTotal) {
+            return MatchCase.LOSE;
+        }
+        throw new IllegalArgumentException("[ERROR] 일치하는 enum이 없습니다.");
    }

-    private int calculateAceScore() {
-        if (!isAceExist() || calculateScore() > 11) {
-            return ACE_ADDITION_NONE_SCORE;
+    public void calculateMoney(MatchCase matchCase, boolean isDealerBlackjack) {
+        if (cards.isBlackjack() && !isDealerBlackjack) {
+            bettingScore = (int) ((int) bettingScore * Game.BLACKJACK_BONUS);
+            return;
+        }
+        if (matchCase.equals(MatchCase.LOSE)) {
+            loseMoney();
+            return;
+        }
+
+        if (matchCase.equals(MatchCase.WIN)) {
+            return;
        }


플레이어가 너무 과도한 책임을 가진게 아닐까요~?
단일책임원칙을 지키고 있지 않아보여요.

jurlring · 2026-03-14T14:08:51Z

src/main/java/view/OutputView.java

+import domain.dto.MatchResultDto;
+import domain.enums.MatchCase;

 public final class OutputView {


Dealer를 플레이어로 생성하게 변경되어, view단에서 도메인 정책에 대한 구현이 들어가는 것 같아요 😿

jurlring · 2026-03-14T14:11:22Z

src/main/java/domain/Deck.java

지금 도메인 규모를 보았을 때는 Aggregate Root까지 나누어 설계해야 할 정도로 복잡한 구조는 아닌 것처럼 보입니다.
그래서 말씀해주신 것처럼 Game이 전체 흐름을 가지고 있는 구조 자체가 크게 어색해 보이지는 않습니다.

보통 Aggregate Root는 여러 객체가 하나의 일관성을 유지하면서 함께 변경되어야 할 때 경계를 나누기 위해 사용하는데, 현재 도메인에서는 그 정도로 큰 경계가 보이지 않는 것 같아요..! 그래서 지금처럼 Game이 플레이어들이나 게임 진행과 관련된 객체들을 관리하는 구조도 충분히 자연스러워 보입니다.

ParkJiYeoung8297 and others added 30 commits March 5, 2026 10:32

feat: 사전학습 Ace 처리 기능 추가

e791dae

feat(domain): 카드 관련 enum 도메인 추가

23b6f2f

feat: Dealer, Player 도메인 템플릿 생성

c842532

feat(Controller): 플레이어 이름 입력 기능 추가

0827d8f

test: Controller 테스트 기본 세팅 추가

cfa77d3

docs: 참가자 입력 기능 명세

390b538

feat: 추가 카드 여부 입력 구현

ee81344

docs: Readme 기능 추가

b018db5

feat(sauter001): 플레이어에게 카드 2 장씩 배분

d25051c

feat(sauter001): 딜러 카드 배분

7b596d6

feat: 참가자 이름과 카드 개수, 카드 출력

015b0b9

docs: Readme update

4f24260

feat(sauter001): 딜러가 추가 카드를 받아야 할 때 처리

12be3c5

refactor: Controller에서 초기화 기능 Servcie 코드로 분리

f7b4483

refactor: 카드 사이즈 메서드 추가

b691c7a

test(service): 카드 생성 및 사이즈 검증 테스트 추가

94cf2f9

docs: Readme update

9c1765e

feat(domain): 카드 합계 기능 구현

c954cf6

test(domain) : 합계 기능 구현 정상 테스트 추가

e8b4052

test: 에이스 고려한 카드 점수 합계 테스트

a8fa42d

feat(sauter001): Ace 1/11 규칙 고려해 카드 합계 계산

ab9e634

feat: 버스트 판단 여부 기능 구현

f0c3269

test(domain): 버스트 판단 여부 테스트 추가

61d9f36

docs: Readme update

14a6ab1

fix: 에이스 11점 적용 안되는 문제 해결

1d2f59d

refactor: 딜러가 카드를 뽑는 메소드명 명확하게 변경

b680504

feat: 카드 결과 판단 기능 구현

f115217

docs: Readme update

cdaa334

feat(sauter001): 블랙잭 승부 결과 클래스 생성

6f32ee7

feat: 블랙잭 승부 계산 (burst 고려)

66ade47

ParkJiYeoung8297 added 29 commits March 11, 2026 00:59

chore: 사용하지 않는 import 제거 및 공백 정리

aa54ea2

refactor: 딜러 상수의 책임을 Dealer 클래스로 이동

de2aee7

refactor & test: 테스트에서만 사용하는 메서드 삭제

76a7600

docs: Readme update

efbdcd0

feat: 배팅 금액 입출력 기능 구현

43b952d

feat: 전체 배팅 금액 구하는 기능 추가

51e71cb

test: 배팅 금액 구하는 테스트 추가

a5eac50

test: 참가자 burst면 배팅 금액 0 되는 정상 테스트 추가

299e57a

fix: burst시 배팅 금액 리셋이 아니라 마이너스로 수정

c0f8714

feat: 최종 수익 출력하는 기능 구현

cc5b709

feat: 배팅 금액 예외 시 재입력 기능 추가

fb87774

feat: 플레이어 burst면 상금 잃는 기능 추가

4fa86c2

feat: 딜러 수익 계산 금액 기능 구현

1a75855

test: 딜러와 플레이어 수익 테스트 추가

16c4615

docs: Readme update

224e4c0

test: 상금 테스트 케이스 추가

4b2dafb

refactor: 전체 카드 Deck 도메인 추가 및 Dealer 삭제 리팩토링

4147342

refactor: 승부 계산 로직 리팩토링

e7718ab

fix&refactor: 배팅 상금 구하는 로직 수정 및 리팩토링

d94b0cc

chore: 메서드 순서 및 공백 정리

980f6bb

fix: dealer를 Game외부에서 주입하도록 수정

de30afc

test: 리팩토링 대상 테스트 수정

5d425df

fix: 블랙잭 여부 판단 오류 수정

18ef51f

fix: 추가 카드 받은 후 출력하는 부분 수정

b1d09ff

refactor: 하드 코딩 상수화

3907f88

test: 테스트 코드 수정

dacc0d0

docs: Readme update

be40df3

docs: Readme update

081470b

jurlring requested changes Mar 14, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[🚀 사이클2 - 미션 (블랙잭 게임 실행)] 아티 미션 제출합니다.#1113

[🚀 사이클2 - 미션 (블랙잭 게임 실행)] 아티 미션 제출합니다.#1113
ParkJiYeoung8297 wants to merge 78 commits intowoowacourse:parkjiyeoung8297from
ParkJiYeoung8297:step2

ParkJiYeoung8297 commented Mar 13, 2026 •

edited

Loading

Uh oh!

jurlring left a comment

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

jurlring Mar 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

ParkJiYeoung8297 commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

사이클 2

기능

사이클1 피드백 반영

To 리뷰어

사이클 1의 PR

미션 중 기록

1. 기능 추가로 인해 수정한 위치 개수

2. 사이클1 때보다 수정 범위가 줄었는가/늘었는가

3. 규칙 적용으로 변경한 코드 1곳

4. 테스트가 설계를 도운 순간 1회

체크 리스트

Uh oh!

jurlring left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ParkJiYeoung8297 commented Mar 13, 2026 •

edited

Loading