oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-blackjack/yrsel/146-2/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,444 @@
+# PR #146 — [블랙잭 2단계] 채넛 미션
+
+- **Reviewee:** [@yrsel](https://github.com/yrsel)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/146
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @Gyuil-Hwnag (두루)
+- **라인 코멘트:** 24 스레드 / 43 코멘트 — *typealias 자가 학습 + Demeter 깊이 토론 + value class 학습* 풍부
+
+## 잘한 점 (설계 관점)
+
+- **`typealias Participants` / `typealias GameFactor` 자가 학습 + 트레이드오프 명시** — 두루 메타 질문 *"typealias 사용하시게 된 이유와 어떠한 장단점 및 특징이 있으셨을지 궁금합니다"* + 학생 자가 답변: *"`typealias` 사용하게 된 이유는 반환값으로 여러 데이터를 한 번에 넘겨야 하는 상황이 있었는데 그 외 다른 곳에서는 사용할 일이 없어서 클래스를 만드는 것보다는 `typealias`를 선택하는 것이 효율적으로 생각되었습니다. 장점으로는 클래스를 생성하지 않아도 이름으로 의미를 전달할 수 있다고 생각되었고 ... 단점으로는 typealias가 어떤 데이터를 담고 있는 지 명시해놓은 부분을 확인해야만 알 수 있다는 점과 클래스인지 typealias 인지 이름만 봤을 때 판단하기 어려워 혼란을 줄 수 있을 것 같습니다."*. **Kotlin typealias 자가 학습 + 트레이드오프 양면 명시 모범**. 두루 자가 답변: *"`typealias`에 대한 의견 정말 좋습니다👍 저는 사실 `typealias`를 잘 사용하지는 않긴 합니다😅"*. **MCP 룰 후보 — `typealias-vs-class`**.
+- **`Score @JvmInline value class + Comparable<Score>`** — *operator compareTo* 자동 구현. *`Score < other`* 자연 표현. PR #136 (밀러 2단계) 의 *Score data class + compareTo* 와 같은 결의 *value class 트레이드오프*.
+- **`Money @JvmInline value class + private constructor + 5 factory (`from / toBlackjackMoney / toWinMoney / toDrawMoney / toLoseMoney / toDealerMoney`)** — *팩토리 패턴 + 도메인 변환 의도 명시*. *원시 박싱 없음 + 타입 안전 + 도메인 어휘*. PR #90·#131·#132·#136·#49 와 같은 결의 *value class*.
+- **`GameStatus.of(score, cardCount)` 정적 팩토리** — *블랙잭 룰 (2장 + 21 점)* 정확 분기. *factory + enum 응집*. PR #131·#90 와 같은 결.
+- **`Dealer.isAvailDrawCard() = hand.score.isDrawableCardByDealer()`** — *Dealer 자기 룰 + Score 메시지*. 다만 *Score 가 *Dealer 룰* 알고 있음* — 못한 점 §3 참고.
+- **`BlackjackInput` interface 도입** — 두루 자가 칭찬: *"Interface의 생성 좋습니다~👍"*. PR #131·#133·#136 와 같은 결의 *DIP*.
+- **YAGNI 자가 학습** — 두루 진단 *"해당 함수는 `targetNumber`에 무조건 ACE만 들어오는군요"* + 학생 자가 인용: *"확장성을 고려해 만들다보니 생긴 코드였습니다. > YAGNI 프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 XP의 원칙이다. ... 앞으로는 위의 규칙에 따라 필요한 기능만을 구현하고 필요하게 되면 리팩터링을 진행해보겠습니다."*. **YAGNI 원칙 자가 학습 + 인용 모범**. PR #136·#137·#88 와 같은 결.
+- **Deck factory 메서드 + 카드 직접 초기화 자가 후속** — 페로로 진단 (이전 PR 인용) + 자가 반영.
+- **`distribute → draw` 메서드명 자가 반영** — 두루 진단 *"`distribute`라는 네이밍이 살짝 눈에 걸리기는 하군요"* + 학생 자가 반영: *"`gameManager.distributeInitialCardWithCount()` vs `gameManager.drawInitialCardWithCount()` 게임 매니저 입장에서 생각해서 분배해준다는 느낌이었어서 `distribute` 라고 명명해봤는데 조금 어색했군요😅 카드를 뽑는다는 의미가 포함되면 조금 더 이해하기 쉬울 것 같아서 `draw` 로 변경했습니다."*. PR #133·#88·#137 와 같은 결의 *naming = 책임 표현*.
+- **`Money.toBlackjackMoney(money) → money.toBlackjackMoney()` Demeter 자가 학습** — 두루 진단 + 학생 자가 답변: *"`Money.toBlackjackMoney(player.money)` : Money 는 Helper 객체인가?, Player의 money를 받아서 blackjack 인 경우 이윤을 알려주나 보구나"* + *"depth가 깊은 것에 대한 생각을 다시 해보게 되었고 depth 깊이보다는 의도를 명확히 표현할 수 있는지가 더 중요하다고 느꼈습니다. 이번 미션에서는 헬퍼 역할보다는 도메인 역할을 기대하고 만들었기에 Money 객체에게 메시지를 전송하는 방식을 선택해보려고 합니다!"*. **Demeter vs 의도 표현 트레이드오프 자가 학습 모범**.
+- **`data class` vs `class` + `toString` 토론** — 두루 메타 질문 + 학생 자가 답변: *"`data class`는 `toString()`, `equals()`, `hashCode()`, `componentN()`, `copy()` 메서드를 제공해주는 이점이 있습니다. 해당 메서드들이 필요한 경우에 `data class`를 선택할 것 같습니다. 그 중 `copy()` 메서드의 경우 List 와 같은 자료구조의 제네릭 타입이 Card, Member, Person 등 참조형일 경우 원소들이 얕은 복사가 진행되는 것으로 알고 있어 사용에 유의해야 할 것 같습니다. View에서 활용할 때 클래스 내에 오버라이딩 된 toString()을 사용한다면 View를 변경하고 싶을 때에도 도메인 코드까지 확인해야 한다는 문제와 여러 군데에서 출력을 위해 호출하지만 출력 형태가 다를 경우 toString()이 어떤 출력 형태를 반환하는 지 알기 어려워 혼란을 줄 수 있을 것 같습니다. 그렇기에 제시해준 방법처럼 Extension 클래스를 생성해서 출력형식을 관리하거나 View 클래스내에서 출력을 위한 형태로 변환해줄 것 같습니다."*. **Kotlin 어휘 + toString trade-off 자가 학습 모범**. PR #88·#137·#90 와 같은 결.
+- **`toUi()` Extension 분리 자가 반영** — 두루 진단: *"toUi() 라는 Extension 부분에 대한 파일을 분리하여 사용한다면, 다른 OutputView에서도 사용을 해볼 수 있겠군요!"* + 학생 자가 반영 (커밋 `55276a`). *Kotlin Extension function 활용 모범*.
+
+## 못한 점 (설계 관점)
+
+### 1. `typealias Participants = Pair<Dealer, List<Player>>` + `typealias GameFactor = Triple<...>` — *현실적 의미 vs 명시성 트레이드오프*
+
+```kotlin
+typealias Participants = Pair<Dealer, List<Player>>
+typealias GameFactor = Triple<Dealer, List<Player>, GameManager>
+
+class BlackjackGame(...) {
+    fun start() {
+        val (dealer, players, gameManager) = gameReady()
+        ...
+    }
+
+    private fun gameReady(): GameFactor { ... }
+    private fun initParticipants(): Participants { ... }
+}
+```
+
+두루 자가 의견: *"만약 사용한다고 하면, `typealias Participants = Pair<Dealer, List<Player>>`까지는 그래도 어떤 것을 반환하는지 조금은 알 수 있어서 활용을 해볼 수 있을 것 같은데, `typealias GameFactor = Triple<Dealer, List<Player>, GameManager>`형태는 지양을 해볼 것 같긴 합니다만, 현재처럼 구현이 길지 않을 때는 사용하는 것도 좋아 보이네요ㅎㅎ💯"*
+
+→ **`typealias` 가 *Pair/Triple* 같은 *익명 묶음에 의미 부여* 시 유용**. *3+ 멤버* 면 *전용 data class* 가 정공. *`GameFactor = Triple<Dealer, List<Player>, GameManager>`* 는 *3 멤버 + 의미 모호* — *클래스 분리* 가 자연. PR #132 (환노 2단계) 의 *Map<X,X> 지양* 와 같은 결의 *익명 컬렉션 회피*.
+
+### 2. `INITIAL_HAND_OUT_CARD_COUNT` Deck 상수 위치 — *룰 위치 모호*
+
+```kotlin
+gameManager.drawInitialCardWithCount(INITIAL_HAND_OUT_CARD_COUNT)
+```
+
+두루 메타 질문: *"`INITIAL_HAND_OUT_CARD_COUNT`는 Deck 에서 상수로 선언을 해두신 이유가 궁금합니다"*
+
+학생 자가 답변: *"블랙잭 게임의 규칙이 처음에 2장이 아닌 1장 또는 3장 등 다양하게 변경될 가능성을 고려해서 인자로 넘겨주었습니다. 불필요한 유지보수 포인트를 만든 것 같다는 생각이 들기는 하네요..😅"*
+
+→ **블랙잭 룰 = "초기 2장 분배"** = *블랙잭 도메인 룰*. *Deck 상수 위치 = Deck 이 분배 룰 알고 있음* — *룰 위치 모호*. *BlackjackGame 또는 GameManager companion* 이 자연. *YAGNI* 학생 자가 인식.
+
+### 3. `Score.isDrawableCardByDealer(): Boolean = number < 17` — *Score 가 Dealer 룰 알고 있음*
+
+```kotlin
+@JvmInline
+value class Score private constructor(val number: Int) : Comparable<Score> {
+    fun isBust(): Boolean = number > BUST_NUMBER
+    fun isBlackjackNumber(): Boolean = number == BUST_NUMBER
+    fun isDrawableCardByDealer(): Boolean = number < DEALER_DRAW_CARD_MINIMUM_SCORE  // ⚠ Dealer 룰
+    ...
+    companion object {
+        private const val ADJUST_ACE_NUMBER = 10
+        private const val DEALER_DRAW_CARD_MINIMUM_SCORE = 17
+        const val BUST_NUMBER = 21
+        ...
+    }
+}
+```
+
+→ **`Score` 가 *Dealer 의 17 룰* 보유**. *Score = 일반 점수 객체*. *`isDrawableCardByDealer` = *Dealer 자기 룰* — *Score 누수***. *Dealer.canDraw() = score.number < 17* 처럼 *Dealer 안에서 직접*이 *룰 위치 정합*. PR #131·#136·#108 (시아) / PR #137·#90 와 같은 결의 *Score 가 도메인 룰 알기*.
+
+### 4. `Score.optimizedSum` 의 `while (countOfAce-- > 0)` — Kotlin 어휘 미숙
+
+```kotlin
+fun optimizedSum(cards: List<Card>): Score {
+    var totalScore: Score = sum(cards)
+    var countOfAce = countOfAce(cards)
+    while (countOfAce-- > 0) {
+        if (totalScore.number > BUST_NUMBER) totalScore -= from(ADJUST_ACE_NUMBER)
+    }
+    return totalScore
+}
+```
+
+→ **`countOfAce-- > 0` = Java/C 어휘**. *Kotlin = `repeat(countOfAce)` 또는 `for (i in 1..countOfAce)`* 가 *어휘 정공*. PR #58·#93·#108·#137 와 같은 결.
+
+또한 *while 안에 if + break 없음* — *aceCount 모두 -10 시도*. *Bust 도달 후 더 차감 시 음수 점수 가능성* — *break 가 *Ace 1 도달 시 종료* 의도*. *현재 코드*는 *Bust 시 매 Ace -10 + Bust 아니면 그대로* — *Bust 후 점수가 0 또는 음수 가능*.
+
+*예: A♠ A♥ A♣ 5♦ = base 4 (Ace 1×3 + 5) → optimizedSum: Bust 아니므로 -10 안 함 → score = 4*. *Ace 11 사용 안 함*.
+*하지만 sum 메서드가 Ace.score = 1* 라 *base 4 = 정확*. *Ace 11 의도면 +10 보너스 적용 별도 필요*.
+
+→ **현재 `optimizedSum` 이 *Ace 1 기본 + Bust 시 -10 반복*** 패턴. *문제* — *Ace 1 기본이면 Bust 아닌 sum 에 +10 보너스 안 함*. *블랙잭 룰 = Ace 11 우선 + Bust 시 1로 변환*. 코드는 *Ace 1 우선 + Bust 시 (이미 Bust 인 케이스만) -10*. **룰 부정확 (Ace 보너스 +10 누락)**.
+
+*수정* = `optimizedSum`이 *Ace 별 11 시도 + Bust 시 1로* 또는 *base sum + Ace 11 보너스 +10 if ≤21*. PR #128·#114·#125·#108·#131·#136·#137·#41 와 같은 결의 표준 패턴 미적용.
+
+### 5. `Money` companion object 의 *5 factory + plus operator* — *Money 가 *Helper 객체* 의문 (학생 자가 인용)*
+
+```kotlin
+@JvmInline
+value class Money private constructor(val amount: Long) {
+    companion object {
+        fun from(amount: Long): Money = Money(amount)
+        fun toBlackjackMoney(money: Money): Money = Money((money.amount * 1.5).toLong())
+        fun toWinMoney(money: Money): Money = Money(money.amount)
+        fun toDrawMoney(): Money = Money(0L)
+        fun toLoseMoney(money: Money): Money = Money(money.amount * -1)
+        fun toDealerMoney(playersProfitSum: Money): Money = Money(playersProfitSum.amount * -1)
+
+        operator fun Money.plus(other: Money): Money = Money(amount + other.amount)
+    }
+}
+```
+
+학생 자가 답변 (Demeter 토론): *"`Money.toBlackjackMoney(player.money)` : Money 는 Helper 객체인가?, Player의 money를 받아서 blackjack 인 경우 이윤을 알려주나 보구나"* — **자가 인식**.
+
+→ **`Money` companion 의 5 변환 factory + plus** = *Helper 객체 측면 강함*. *도메인 객체 = 자기 상태 + 메시지*. *현재 `Money` 가 *변환 헬퍼*에 가까움*. *`money.toBlackjack(): Money` 같은 *멤버 메서드*가 *Tell-Don't-Ask 정공*. *operator plus* 만 *멤버 메서드* — 비대칭.
+
+학생 자가 후속 의도 = *`Money.toBlackjackMoney → money.toBlackjackMoney()` 자가 변경* (Demeter + 도메인 객체 의도).
+
+### 6. `Money.operator fun Money.plus(other: Money)` companion object 안 — *Kotlin 어휘 어색*
+
+```kotlin
+companion object {
+    ...
+    operator fun Money.plus(other: Money): Money = Money(amount + other.amount)
+}
+```
+
+→ **`operator fun Money.plus` = extension function on Money** — *companion 안에 정의*. *Kotlin Extension function* 패턴이지만 *companion 위치*가 *함수 접근*에 제한 — *호출자가 import Money.Companion.plus* 필요. *멤버 함수 `operator fun plus(other: Money): Money`* 가 *간결*. PR #133·#90·#137 와 같은 결의 *operator 멤버*.
+
+### 7. `Hand` 가 *외부 노출 (`val hand = Hand()`)* — Participant 책임 모호
+
+```kotlin
+open class Participant(val name: String) {
+    val hand = Hand()  // ⚠ public
+
+    fun addCard(card: Card) = hand.addCard(card)
+    fun isBust(): Boolean = GameJudge.judge(hand) == GameStatus.BUST
+}
+```
+
+두루 진단 (Participant.kt:10 — 미해결): *"흠~ 현재와 같은 구조에서는 해당 방법밖에는 없을 것 같기는 하겠네요...🥲 아니면 한가지 방법이 있을 수도 있겠군요! `Participant 에서 Hand()를 상속받는 형태`로요"*
+
+→ **`Participant.hand` 외부 노출**. *호출자가 `participant.hand.cards`* 접근 가능. *Demeter 위반 표면*. *Participant.cards() / Participant.score()* 위임 메서드가 정공. PR #88·#133·#108·#137 와 같은 결.
+
+*두루 권고 = Participant 가 Hand 상속* — *카드 메시지 = Participant 자기 메시지*. *상속 vs 위임* 트레이드오프 — *Composition over Inheritance* 와 *상속의 직접성* 의 균형.
+
+### 8. `Dealer.isBlackjack()` + `Participant.isBust()` 두 메서드 — *Participant 다형성 부재 신호*
+
+```kotlin
+open class Participant(val name: String) {
+    ...
+    fun isBust(): Boolean = GameJudge.judge(hand) == GameStatus.BUST
+}
+
+class Dealer(name: String = DEALER_NAME) : Participant(name) {
+    fun isBlackjack(): Boolean = GameJudge.judge(hand) == BLACKJACK
+    fun isAvailDrawCard(): Boolean = hand.score.isDrawableCardByDealer()
+    ...
+}
+
+class Player(name: String, val money: Money) : Participant(name)
+```
+
+→ **`isBlackjack` Dealer만 + `isBust` Participant 공통 + `isAvailDrawCard` Dealer만**. *Player.isAvailDrawCard 부재* — *외부 람다 (`playerDrawDecision`) 의존*. *Player.canHit() = !isBust && needsMore (입력) 다형성*이 *PR #49·#108·#132 등 와 같은 결*. 현재는 *Player 다형성 메서드 부재*.
+
+또한 *`open class Participant`* — *abstract 가 아닌 open*. *PR #131·#132·#136·#49 의 abstract Participant* 와 *반대 트레이드오프*.
+
+### 9. `ProfitCalculator object` — *정적 헬퍼 = Tell-Don't-Ask 미달 (자가 인식 + 후속 반영)*
+
+```kotlin
+object ProfitCalculator {
+    fun calculateProfit(dealer: Dealer, player: Player): Money =
+        getMoneyByGameStatusOrNull(dealer, player) ?: getMoneyByCompareToScore(dealer, player)
+    ...
+}
+```
+
+→ **`ProfitCalculator object` = 정적 헬퍼**. *Player.calculateProfit(dealer): Money* 같은 *Player 메시지*가 *Tell-Don't-Ask*. PR #131·#136·#132·#49 와 같은 결의 *정적 헬퍼 회피*.
+
+학생 자가 학습 (Score.kt:9 토론): *"-> 해당 부분을 바꿔보니 util 기능에 가깝다고 느껴졌던 ScoreCalculator 대신 도메인 객체로 관리할 수 있다는 점이 유용한 것 같습니다."* — *Score → 도메인 객체 자가 인식 + Profit 도 같은 결로 변환 의도*.
+
+### 10. `BlackjackGame.dealerDrawCards` — *한 번만 draw + return Boolean*
+
+```kotlin
+private fun dealerDrawCards(gameManager: GameManager) {
+    val isDraw = gameManager.isDrawCardBasedOnDealer()
+    outputView.printDealerHandStatus(isDraw)
+}
+
+// GameManager
+fun isDrawCardBasedOnDealer(): Boolean {
+    if (dealer.isAvailDrawCard()) {
+        drawCard(dealer)
+        return true
+    }
+    return false
+}
+```
+
+→ **`isDrawCardBasedOnDealer()` 호출 한 번 = Dealer 카드 1장 받거나 안 받음**. *Dealer 룰 = 17 이상까지 hit* = *호출자가 반복 호출 강제*. *Tell-Don't-Ask 미달 (PR #152 모찌 와 같은 결)*. *`dealer.drawUntilStand(deck)`* 같은 *Dealer 자기 메시지*가 정공. 또는 *while (dealer.canDraw()) { dealer.draw(deck) }* 내부 응집.
+
+`BlackjackGame.dealerDrawCards` 가 *Dealer 카드 1장 + 메시지 출력* — *Dealer 가 17 도달 시 호출 종료* 없음. *현재 코드 = 단 1회 호출* — *룰 부정확*. 실제로는 *Dealer 카드 한 번만 받을 가능성 (16→17 도달)* 인데 *16 → 13 (5 카드 인출 후)* 같은 *여러 번 hit 케이스 미반영*.
+
+다만 *호출자가 매번 호출 반복*하면 동작. *현재 BlackjackGame.dealerDrawCards = 한 번만 호출* — *룰 부정확 가능성*. **루프 부재**.
+
+### 11. `Player.money: Money` 외부 노출 — *베팅금 외부 변경 가능성*
+
+```kotlin
+class Player(name: String, val money: Money) : Participant(name)
+```
+
+→ **`val money: Money` 외부 노출**. *val* 이라 *교체 불가*. *Money = value class + immutable* — *변경 불가*. *PR #58 의 외부 가변 변경 우려* 와 *반대 결* (Money 자체 불변).
+
+학생 자가 답변 (Money.kt 토론): *"Money 객체가 Player의 생성자로 있어야하는 이유는 알맞은 위치를 찾지 못해 그렇게 구현했던 것 같습니다. 현재 Player는 부모인 Participant 프로퍼티까지 생각한다면 4개의 인스턴스를 갖게되어 요구사항도 만족시키지 못하게 되었습니다.😟 사실 Player와 Money를 상태를 갖고 있는 PlayerTable 의 이름의 객체를 생성했었습니다. 현재 구조에서 Player 역할이 모두 PlayerTable을 통해서 수행되어야 했기에 많은 부분이 변경되다보니 잘못된 설계로 인해 변경부분이 많다고 생각되어 임시로 Player 프로퍼티로 갖게 되었습니다. Player와 Money를 감싸는 Wrapper가 있다면 인스턴스 개수에 대한 요구조건은 만족할 수 있겠으나 List<Player>를 모두 List<Wrapper> 와 같이 변경해야하다보니 더 좋은 방법이 있을 지 고민중입니다."*
+
+→ **3 변수 제약 토론 = 학생 자가 회의 + 임시 결정**. *Participant.name + Participant.hand + Player.money = 3 변수*. *제약 위반*. *PlayerTable Wrapper 시도 후 잘못된 설계 자가 인식 + 후퇴*. **3 변수 제약 = 연습 도구 인식 + 학생/리뷰어 양방향 학습** (PR #133·#88·#132·#136·#41·#49 와 같은 결).
+
+### 12. `GameStatus enum` 의 `STAY` 상태 — *Stay 자체 vs 진행 상태*
+
+```kotlin
+enum class GameStatus {
+    BLACKJACK,
+    BUST,
+    STAY,
+    ;
+
+    companion object {
+        fun of(score: Score, cardCount: Int): GameStatus {
+            if (score.isBlackjackNumber() && cardCount == INITIAL_HAND_OUT_CARD_COUNT) return BLACKJACK
+            if (score.isBust()) return BUST
+            return STAY
+        }
+    }
+}
+```
+
+→ **`STAY = else fallback`** = *블랙잭/Bust 아니면 STAY*. *진행 중 (Hit 가능) + Stay (자발 정지) 구분 부재*. *PR #152·#136·#93·#85 의 Hit/Stay 별도 상태* 와 *반대 트레이드오프*. *STAY = 결과 상태 (분기 후 비교)*. *Hit 도 STAY 로 흡수* — *상태 표현 부족*. *enum 3개로 단순화 + 분기 응집* vs *상태 객체 다형성* 의 트레이드오프.
+
+### 13. `ProfitCalculator` 의 *2 단계 분기 (`?:`) 흐름* — *Tell-Don't-Ask 미달*
+
+```kotlin
+fun calculateProfit(dealer: Dealer, player: Player): Money =
+    getMoneyByGameStatusOrNull(dealer, player) ?: getMoneyByCompareToScore(dealer, player)
+```
+
+→ **`getMoneyByGameStatusOrNull` 가 *BLACKJACK / BUST 분기 + null fallback*** + **`getMoneyByCompareToScore` 가 *점수 비교***. *2 단계 정적 헬퍼*. *Player.profit(dealer): Money* 같은 *Player 메시지*가 *책임 응집*. PR #131·#136·#132·#137 와 같은 결.
+
+또한 *`getMoneyByGameStatusOrNull` 반환 Money?* — *nullable* 가 *fallback 신호*. *Money.NONE / Money.zero()* 같은 *명시적 null object* 패턴이 *호출자 안전성*. 다만 *현재 ?:* 흐름은 *Kotlin 어휘로 간결*.
+
+### 14. `Dealer` 가 *기본 생성자 noargs + companion DEALER_NAME default* — 정공
+
+```kotlin
+class Dealer(name: String = DEALER_NAME) : Participant(name) { ... }
+```
+
+→ **default 값 = 도메인 표준 ("딜러")**. PR #131·#137·#136·#108·#133 와 같은 결의 *Dealer 기본 이름*. *외부 변경 불가능 (val)* + default 일관.
+
+### 15. `BlackjackGame.gameReady` / `gameStart` / `gameResult` — *3 단계 함수 분리 + Controller 책임 흡수*
+
+```kotlin
+fun start() {
+    val (dealer, players, gameManager) = gameReady()
+    gameStart(dealer, players, gameManager)
+    gameResult(dealer, players, gameManager)
+}
+```
+
+학생 자가 답변 (Controller 토론): *"해당 구조는 여러 컨트롤러에서 사용해야하는 경우 추상화된 View 구현체만 존재한다면 쉽게 적용할 수 있다는 장점이 있을 것 같습니다. 하지만 현재 프로그램에서는 단순하게 컨트롤러를 2번 타고 들어가는 느낌이라 효율적이진 못한 것 같습니다."*
+
+두루 답변: *"현재 구현을 보면 `BlackjackGame`은 컨트롤러의 느낌이 강하기는 하다는 생각이 듭니다. `View의 값을 받아서 객체를 생성하고 블랙잭 게임이 돌아가도록 진행의 흐름을 관리`하여 Controller의 느낌이 강합니다!"*
+
+→ **BlackjackGame = Controller 변형**. PR #131·#132·#136·#152 와 같은 결의 *Engine god-object*. *학생 자가 회의 + reviewer 동의 = 트레이드오프 인식*.
+
+### 16. `GameManager.processDrawOrStayBasedOnPlayer` 복잡한 메서드명
+
+```kotlin
+fun processDrawOrStayBasedOnPlayer(
+    player: Player,
+    playerDrawDecision: (Player) -> CardDrawDecision,
+    showPlayerHands: (Player) -> Unit,
+) { ... }
+```
+
+→ **`processDrawOrStayBasedOnPlayer` = *길고 의미 모호***. *Kotlin 어휘 = `playPlayerTurn(player, ...)` 또는 `runPlayerRound(player, ...)`* 가 *간결*. *process + BasedOn* 접두사 어색. PR #137 (지훈 권고: `onXX`) 와 같은 결의 *콜백 어휘*.
+
+### 17. `Score.isBlackjackNumber() = number == 21` — *블랙잭 ≠ 21 점*
+
+```kotlin
+fun isBlackjackNumber(): Boolean = number == BUST_NUMBER  // 21
+```
+
+→ **`isBlackjackNumber` = *21 점***. *블랙잭 룰 = 2장 + 21*. *3장 21 도 isBlackjackNumber == true*. *naming misleading*. *isMaxScore() = 21 점* / *블랙잭 판정은 GameStatus.of 에서 cardCount 함께 검사* — 룰은 정합. 다만 *Score 메서드 이름*에 *블랙잭* 들어가면 *호출자 오해 가능성*.
+
+### 18. `ScoreCalculator → Score 변경 트레이드오프* — 학생 자가 학습*
+
+두루 진단 (Score.kt:9): *"사실 이전에 ScoreCalculator를 만들어 보도록 하게 코멘트를 남겨두었던 이유는, 현재처럼 Score객체가 만들어 지다보면, 객체간의 뎁스가 깊어지는 형태가 될 수 있어서 Utils 형식으로 점수 계산기를 만들어보도록 했었어요!"*
+
+→ **Helper (ScoreCalculator) vs 도메인 객체 (Score) 트레이드오프**. *Helper = 깊이 ↓ + 도메인 누수*. *도메인 객체 = 깊이 ↑ + 책임 응집*. *학생 자가 결정 = 도메인 객체*. PR #131·#136·#137·#90 와 같은 결의 *Score 객체 분리*.
+
+### 19. `GameManager.fold` 함수형 어휘 활용
+
+```kotlin
+fun getDealerProfit(playersProfitInfo: List<ParticipantProfitInfo>): ParticipantProfitInfo {
+    val playersSum = playersProfitInfo.fold(Money.from(0L)) { sum, player -> sum + player.profit }
+    return ParticipantProfitInfo(dealer.name, Money.toDealerMoney(playersSum))
+}
+```
+
+→ **`fold` 사용 = Kotlin 함수형 어휘**. *PR #49 의 var profit + forEach* 와 *반대 트레이드오프* — *함수형 정공*. *operator plus*도 활용. PR #131·#132·#133·#137 와 같은 결.
+
+### 20. `BlackjackGame.gameStart` 의 *Dealer 블랙잭 조기 종료* — 정확
+
+```kotlin
+private fun gameStart(...) {
+    if (!dealer.isBlackjack()) {
+        playersDrawCards(...)
+        dealerDrawCards(...)
+    }
+}
+```
+
+→ **딜러 블랙잭 시 모든 진행 skip**. *카지노 룰 = 딜러 블랙잭 시 플레이어 블랙잭 만 무승부, 나머지 패배*. PR #137·#136 와 같은 결의 *블랙잭 룰 정확성*.
+
+## 리뷰어 의견 요지
+
+- **typealias = Pair/Triple 익명 의미 부여 시 유용, 3+ 멤버 시 클래스** — 트레이드오프 양면 명시.
+- **`distribute → draw` naming = 책임 표현** — *카드 뽑는 메시지*.
+- **Demeter vs 의도 표현 트레이드오프** — *깊이 < 의도*. *Money.toBlackjackMoney vs money.toBlackjackMoney() 양쪽 합리*.
+- **YAGNI 원칙** — *확장성 고려 < 필요할 때 구현*.
+- **`ScoreCalculator` (Helper) vs `Score` (도메인 객체)** — *깊이 + 책임 응집 트레이드오프*.
+- **value class + @JvmInline = 원시 박싱 없음 + 도메인 어휘** — *학생 자가 학습 모범*.
+- **`data class` vs `class` + `toString` 활용** — *학생 자가 학습 + 의견 풍부*.
+- **`toUi()` Extension 분리 = 다른 View 재사용 가능** — *Kotlin Extension function 활용*.
+- **3 변수 제약 = 연습 도구** — *Wrapper 시도 후 잘못된 설계 인식 자가 후퇴*.
+- **BlackjackGame = Controller 느낌 강함** — *학생 자가 회의 + reviewer 동의*.
+
+## 대표 인용
+
+**두루 (typealias 트레이드오프 인정, BlackjackGame.kt:10):**
+> `typealias`에 대한 의견 정말 좋습니다👍
+> 저는 사실 `typealias`를 잘 사용하지는 않긴 합니다😅
+> 이유는 채넛이 말씀해주신대로, `어떤 데이터를 담고 있는 지 명시해놓은 부분을 확인`을 해야하기 때문이에요
+> 구현하는 내용이 많아지다 보면 네이밍에 명확하게 드러나지 않는다면, 직접 구현을 한 저도 몇달 몇년 뒤에 내용을 살펴볼 때 결국엔 `어떤 것 데이터인지 결국에는 찾아봐야만`해서요..
+>
+> 만약 사용한다고 하면, `typealias Participants = Pair<Dealer, List<Player>>`까지는 그래도 어떤 것을 반환하는지 조금은 알 수 있어서 활용을 해볼 수 있을 것 같은데, `typealias GameFactor = Triple<Dealer, List<Player>, GameManager>`형태는 지양을 해볼 것 같긴 합니다만, 현재처럼 구현이 길지 않을 때는 사용하는 것도 좋아 보이네요ㅎㅎ💯
+
+**두루 (Demeter vs 의도, ProfitCalculator.kt:24):**
+> 어떻게 로직이 구성되어 있는지 모르고 딱 해당 부분의 코드만 봤을 때, 아래와 같은 생각이 처음에 들기는 했었어요
+> - `Money.toBlackjackMoney(player.money)` : Money 는 Helper 객체인가?, Player의 money를 받아서 blackjack 인 경우 이윤을 알려주나 보구나
+> - `player.money.toBlackjackMoney()` : 뎁스가 깊기는 한데, 블랙잭에 이윤을 알려주는 거긴 하구나
+> ...
+> 참고로 뎁스 형식이 무조건적으로 나쁜것만은 아니긴 합니다
+> 그치만 뎁스 형식으로 한다면, 수정들에 대해서 유의해야 하는 단점도 있습니다
+
+**두루 (Helper vs 도메인 객체 트레이드오프, Score.kt:9):**
+> 아하~ Score객체가 추가되었군요!👍
+> ...
+> 사실 이전에 ScoreCalculator를 만들어 보도록 하게 코멘트를 남겨두었던 이유는, 현재처럼 Score객체가 만들어 지다보면, 객체간의 뎁스가 깊어지는 형태가 될 수 있어서 Utils 형식으로 점수 계산기를 만들어보도록 했었어요!
+
+**두루 (BlackjackGame = Controller 느낌, BlackjackController.kt:10):**
+> 현재 구현을 보면 `BlackjackGame`은 컨트롤러의 느낌이 강하기는 하다는 생각이 듭니다
+> `View의 값을 받아서 객체를 생성하고 블랙잭 게임이 돌아가도록 진행의 흐름을 관리`하여 Controller의 느낌이 강합니다!
+
+**학생 자가 학습 (typealias 장단점, BlackjackGame.kt:10):**
+> `typealias` 사용하게 된 이유는 반환값으로 여러 데이터를 한 번에 넘겨야 하는 상황이 있었는데 그 외 다른 곳에서는 사용할 일이 없어서 클래스를 만드는 것보다는 `typealias`를 선택하는 것이 효율적으로 생각되었습니다.
+>
+> 장점으로는 클래스를 생성하지 않아도 이름으로 의미를 전달할 수 있다고 생각되었고 현재 사용코드에서의 Triple, Pair 같은 경우 data class로 구현되어 있기에 data class 에서 제공하는 기능인 componentN()도 활용할 수 있듯이 타입 또는 자료구조의 기능을 동일하게 사용할 수 있다는 점이 장점이라고 생각합니다.
+> 단점으로는 typealias가 어떤 데이터를 담고 있는 지 명시해놓은 부분을 확인해야만 알 수 있다는 점과 클래스인지 typealias 인지 이름만 봤을 때 판단하기 어려워 혼란을 줄 수 있을 것 같습니다.
+
+**학생 자가 학습 (YAGNI 원칙 인용, ScoreCalculator.kt):**
+> 확장성을 고려해 만들다보니 생긴 코드였습니다.
+>
+> > YAGNI 프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 XP의 원칙이다.
+>  "실제로 필요할 때 무조건 구현하되, 그저 필요할 것이라고 예상할 때에는 절대 구현하지 말라."
+>
+> 앞으로는 위의 규칙에 따라 필요한 기능만을 구현하고 필요하게 되면 리팩터링을 진행해보겠습니다.
+
+**학생 자가 학습 (Demeter vs 의도 표현, ProfitCalculator.kt:24):**
+> `Money.toBlackjackMoney(player.money) : Money 는 Helper 객체인가?, Player의 money를 받아서 blackjack 인 경우 이윤을 알려주나 보구나`
+> `player.money.toBlackjackMoney() : 뎁스가 깊기는 한데, 블랙잭에 이윤을 알려주는 거긴 하구나`
+>
+> 라는 설명을 보니 `depth`가 깊은 것에 대한 생각을 다시 해보게 되었고 `depth` 깊이보다는 의도를 명확히 표현할 수 있는지가 더 중요하다고 느꼈습니다.
+>
+> 이번 미션에서는 헬퍼 역할보다는 도메인 역할을 기대하고 만들었기에 `Money` 객체에게 메시지를 전송하는 방식을 선택해보려고 합니다!
+
+**학생 자가 학습 (data class + toString trade-off, ParticipantProfitInfo.kt:8):**
+> `data class`는 `toString()`, `equals()`, `hashCode()`, `componentN()`, `copy()` 메서드를 제공해주는 이점이 있습니다.
+> 해당 메서드들이 필요한 경우에 `data class`를 선택할 것 같습니다.
+> 그 중 `copy()` 메서드의 경우 List 와 같은 자료구조의 제네릭 타입이 Card, Member, Person 등 참조형일 경우 원소들이 얕은 복사가 진행되는 것으로 알고 있어 사용에 유의해야 할 것 같습니다.
+>
+> `View`에서 활용할 때 클래스 내에 오버라이딩 된 `toString()`을 사용한다면 `View`를 변경하고 싶을 때에도 도메인 코드까지 확인해야 한다는 문제와 여러 군데에서 출력을 위해 호출하지만 출력 형태가 다를 경우 `toString()`이 어떤 출력 형태를 반환하는 지 알기 어려워 혼란을 줄 수 있을 것 같습니다.
+> 그렇기에 제시해준 방법처럼 Extension 클래스를 생성해서 출력형식을 관리하거나 View 클래스내에서 출력을 위한 형태로 변환해줄 것 같습니다.
+
+**학생 자가 학습 (3 변수 제약 자가 회의, Money.kt):**
+> 사실 Player와 Money를 상태를 갖고 있는 `PlayerTable` 의 이름의 객체를 생성했었습니다.
+> 현재 구조에서 Player 역할이 모두 `PlayerTable`을 통해서 수행되어야 했기에 많은 부분이 변경되다보니 잘못된 설계로 인해 변경부분이 많다고 생각되어 임시로 `Player` 프로퍼티로 갖게 되었습니다.
+
+## 얻은 교훈
+
+1. ***`typealias` = Pair/Triple 익명 의미 부여 시 유용, 3+ 멤버 시 data class***. *2 멤버 (Pair<Dealer, List<Player>>) = typealias 합리*. *3 멤버 (Triple<Dealer, List<Player>, GameManager>) = data class 가 명시*. 트레이드오프 양면 인식 + reviewer 자가 사용 의견. **MCP 룰 후보 — `typealias-vs-class`** (3+ 멤버 시 클래스 권고).
+
+2. ***Demeter vs 의도 표현 트레이드오프 = 깊이 < 의도***. *`Money.toBlackjackMoney(player.money)` (Helper 느낌) vs `player.money.toBlackjackMoney()` (도메인 메시지)* 의 *둘 다 합리*. *깊이 깊은 것이 무조건 나쁜 것 X*. *의도 명료성 우선*. PR #133·#88·#137·#108 와 같은 결.
+
+3. ***YAGNI = 필요할 때 무조건 구현, 예상할 때 절대 구현 X***. *학생 자가 인용 + 후속 반영*. *확장성 고려가 만든 dead code*. *현재 사용처에서 시작 + 필요 시 추가* 정공. PR #136·#137·#88·#103 와 같은 결.
+
+4. ***ScoreCalculator (Helper) vs Score (도메인 객체) 트레이드오프***. *Helper = 깊이 ↓ + 책임 분산*. *도메인 객체 = 깊이 ↑ + 책임 응집*. *학생 자가 결정 = 도메인 객체 + 의도 명시* 모범. PR #131·#136·#137·#90 와 같은 결.
+
+5. ***`@JvmInline value class + Comparable + operator overloading + private constructor + factory` Kotlin 어휘 종합 활용***. *Score / Money 둘 다 활용*. PR #90·#131·#132·#136·#137 와 같은 결.
+
+6. ***`Score.isDrawableCardByDealer() = number < 17` Score 가 Dealer 룰 알기 = 룰 누수***. *Dealer.canDraw() = score < 17 안*에서 직접*이 정공*. PR #131·#136·#108·#137·#90 와 같은 결.
+
+7. ***Ace 보너스 +10 패턴 누락 가능성***. *`optimizedSum` 이 *Ace 1 기본 + Bust 시 -10 반복** — *Bust 아닌 Ace 11 시도 부재*. *현재 코드 룰 부정확*. *Ace 11 우선 + Bust 시 1 변환* 또는 *base + Ace 보너스 +10 if ≤21* 표준 패턴. PR #128·#114·#125·#108·#131·#136·#137·#41 와 같은 결.
+
+8. ***`distribute → draw` naming = 책임 표현 (카드 뽑는 메시지)***. *분배자 입장 vs 행위 입장*. *draw 가 *카드 뽑기 메시지* 어휘 정공*. PR #133·#88·#137·#136 와 같은 결.
+
+9. ***`toString` View 활용 트레이드오프***. *도메인 객체 내 toString = View 변경 시 도메인 수정*. *Extension function (`.toUi()`) 분리 = 다른 View 재사용*. *학생 자가 학습 + Extension 분리 정공*. PR #88·#137·#90 와 같은 결.
+
+10. ***3 변수 제약 = 연습 도구, Wrapper 시도 + 잘못된 설계 자가 후퇴***. *학생 PlayerTable Wrapper → 변경 파급 ↑ → 임시 Player 프로퍼티 보유 결정*. *Reviewer 두루 동의*. PR #133·#88·#132·#136·#41·#49 와 같은 결.
+
+11. ***BlackjackGame = Controller 느낌 자가 회의 + reviewer 동의***. *학생 + reviewer 양방향 트레이드오프 인식*. *Game 도메인 객체 vs Controller 변형 경계 모호*. PR #131·#132·#136·#152·#58 와 같은 결.
+
+12. ***`open class Participant` vs abstract class 트레이드오프***. *open = 인스턴스화 가능 + 자식 override 가능*. *abstract = 인스턴스화 불가 + abstract method 강제*. *PR #49·#131·#132·#136 의 abstract 다형성* 와 *반대 트레이드오프*. *PR #146 = open + 공통 행동 + Player/Dealer 자기 메서드*.
+
+13. ***`Hand` 외부 노출 (`val hand`) = Demeter 위반 표면***. *Participant.cards() / Participant.score()* 위임 메서드가 정공. *두루 권고 = Participant 가 Hand 상속* 도 대안. PR #88·#133·#108·#137 와 같은 결.
+
+14. ***`ProfitCalculator object` 정적 헬퍼 + nullable fallback (`?:`)*** — *Tell-Don't-Ask 미달*. *Player.profit(dealer): Money* 같은 *Player 메시지*가 정공. *학생 자가 인식 (ScoreCalculator → Score 변환) + ProfitCalculator 도 같은 결*. PR #131·#136·#132·#137·#49 와 같은 결.
+
+15. ***`fold` 함수형 어휘 = Kotlin 정공***. *var + forEach* 대신 *fold/sumOf*. *Money + Money operator plus* 활용. PR #131·#132·#133·#137·#49 와 같은 결.
+
+16. ***`processDrawOrStayBasedOnPlayer` 길고 모호한 메서드명 vs `onXX` 콜백 어휘***. *PR #137 의 onEndDealerTurn* 와 *반대 트레이드오프*. *`playPlayerTurn(player, ...)` 같은 *명사+동사 한 단어* 가 *Kotlin 어휘 정공*.
+
+17. ***학생 자가 학습 + reviewer 자가 의견 + 트레이드오프 양면 인식 = 학습 가시화 최고 수준***. *typealias / Demeter vs 의도 / Helper vs 도메인 / data class vs class / 3 변수 제약* 모두 *양면 트레이드오프 인식 + 결정 근거 명시*. PR #128·#135·#108·#133·#136·#137·#41·#88 와 같은 결.
+
+18. ***`STAY = else fallback` enum 단순화 vs State 객체 다형성 트레이드오프***. *PR #146 = enum 3개 단순* / *PR #152·#136·#93·#85 = State 객체 다형성*. *enum + GameStatus.of factory* 가 *간결 + 분기 응집*. *State 객체*는 *상태별 행동 차이 표현*. *둘 다 합리*.
+
+19. ***딜러 카드 한 번만 뽑기 = 룰 부정확 가능성***. *`isDrawCardBasedOnDealer()` 한 번 호출 = 1장 받음*. *Dealer 룰 = 17 이상까지 hit* — *호출자가 반복 호출 강제*. *Dealer.drawUntilStand(deck)* 내부 응집 정공. PR #152 (모찌) 의 *dealerTurn while + return 논리 오류* 와 같은 결의 *Dealer 자기 룰 응집 부재*.

package/lessons/woowacourse-kotlin-lotto/2chang5/27-1/353/213/250/352/263/204-/353/241/234/353/230/220.md

@@ -0,0 +1,155 @@
+# PR #27 — [멧돼지] 1단계 로또
+
+- **Reviewee:** [@2chang5](https://github.com/2chang5)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/27
+- **단계:** 1단계
+- **리뷰어:** @laco-dev
+- **라인 코멘트:** 70
+
+## 잘한 점 (설계 관점)
+
+- **`PurchaseMoney`, `LottoBunch`, `WinningLotto`, `WinningResult` 도메인 분리**.
+- **`Bank` 객체 시도** (이름은 모호).
+- **`Validator` 분리**.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller가 ","로 split하기 + Int 검증
+
+```kotlin
+class LottoController {
+    fun run() {
+        val moneyInput = InputView.readMoney()  // Int 반환
+        val purchaseMoney = PurchaseMoney(moneyInput)
+.
+        val winningInput = InputView.readWinningNumbers()
+        val numbers = winningInput.split(",").map { it.trim().toInt() }  // ⚠ Controller가 파싱
+.
+    }
+}
+```
+
+리뷰어 핵심:
+
+> 위 코드에서 InputView로부터 받아야 하는 값은 Int 값이 됩니다. 그런데 이 Int는 무엇으로 부터 만들어졌는지, 컨트롤러가 알 필요가 있을까요? 콘솔로부터 받을 수도 있고, 유저가 화면을 터치해서 받을 지도 모릅니다. 근본적으로 만들고 싶은 것은 PurchaseMoney이고 무엇으로 부터 필요한 Int를 만들지는 InputView의 구현의 책임으로 간다고 생각합니다.
+
+→ Controller는 `PurchaseMoney`라는 도메인을 받기를 원할 뿐, *콘솔/터치/CSV* 같은 입력 형식은 무지해야.
+
+→ "domain 레이어는 view를 알면 안되지만, view에서는 domain을 알기 때문에 저는 InputView에서 바로 domain 모델을 만드는 방법을 선호하는 편입니다."
+
+### 2. Controller 안에 일반화된 입력 헬퍼 — `Any` 반환
+
+```kotlin
+private fun <T> getValidInput(input: () -> T, validator: (T) -> Unit): Any {
+    while (true) {
+        try {
+            val result = input()
+            validator(result)
+            return result
+        } catch (e: IllegalArgumentException) {. }
+    }
+}
+```
+
+리뷰어:
+
+> 위 함수들의 목적과 역할이 단순히 코드 반복을 줄이려고 만들어 졌지만, 여러가지 높은 위험성을 가지고 있습니다.
+> 1. Any 타입을 반환하기 때문에 강제로 캐스팅 하는 등 타입 안전성에 대한 위험성
+> 2. 특정 오류를 일반화 시킴으로써 예외 처리가 의도치 않게 동작할 수 있다는 위험성
+
+→ 일반화의 비용 = 타입 안전성. 미션 규모에서는 *중복을 허용*.
+
+### 3. 상수 파일 `LottoRule.kt`가 도메인 정보 보유
+
+```kotlin
+object LottoRule {
+    const val MIN_NUMBER = 1
+    const val MAX_NUMBER = 45
+    const val LOTTO_SIZE = 6
+}
+```
+
+리뷰어:
+
+> 로또의 최솟값과 최댓값은 로또 번호가 가지는 명확한 개념이 아닐까요? 이 값을 공통으로 사용하게 되면, 로또 번호에게 협력을 하지 않고 모두 가져다 쓰는 문제가 될 수 있습니다. 로또 번호에게 필요한 내용을 요청해서 받아오도록 만들어 보세요.
+
+→ MIN/MAX 같은 도메인 invariant는 `LottoNumber` 객체의 영역. 상수로 노출하면 외부에서 가져다 쓰며 도메인이 *수동적*이 됨.
+
+### 4. `Bank` — 이름과 책임 불명확
+
+```kotlin
+class Bank(.) {
+    fun calculate(.): Double =.  // 수익률만 계산
+}
+```
+
+리뷰어:
+
+> Bank는 무슨 의미를 가진다고 생각하셨나요? 이 객체의 역할과 이름이 잘 드러나도록 작성이 되었을까요?
+
+→ "Bank"가 *금융 기관*인지, *결과 계산기*인지, *상금 보유자*인지 모호.
+
+### 5. `Bank` 내부에서 외부 객체 정보 직접 꺼내기 (feature-envy)
+
+```kotlin
+class Bank {
+    fun calculate(lottoBunch: LottoBunch, winningResult: WinningResult): Double {
+        val purchaseMoney = lottoBunch.size * LOTTO_PRICE  // ⚠ 다른 객체 정보 꺼내기
+        val prize = winningResult.totalPrize()
+        return prize.toDouble() / purchaseMoney
+    }
+}
+```
+
+> 각 객체에 있는 값을 직접 꺼내와서 로직을 처리하지 않고, 객체에 요청을 보내서 원하는 값을 처리하도록 해보세요. 객체지향 에서는 이 개념을 메시지를 보낸다 라고 표현합니다.
+
+### 6. Grade → Rank 리네임 후 함수명 그대로
+
+```kotlin
+enum class Rank(.) {
+.
+    fun calculateGradePrize(.): Int =.  // ⚠ Grade 시절 이름
+}
+```
+
+> 구현하면서 Grade에서 Rank로 변경된 것 같은데 함수 이름은 남아있는 것 처럼 보이네요
+
+### 7. `Rank.prizeMoney`가 property + 동명 함수 둘 다
+
+```kotlin
+enum class Rank(val prizeMoney: Int) {
+.
+    fun getPrizeMoney(): Int = prizeMoney  // ⚠ 중복
+}
+```
+
+> Rank가 prizeMoney를 프로퍼티로 가지고 있는데, 이 함수의 목적은 무엇일까요?
+
+## 리뷰어 의견 요지
+
+리뷰어 @laco-dev의 핵심 메시지:
+
+1. **InputView가 *도메인 객체*를 반환** — Controller가 파싱/검증/조립을 모르게. "view → domain 의존은 허용".
+
+2. **도메인 invariant는 도메인 객체에**. `LottoRule` 같은 상수 파일은 god-folder 패턴. `LottoNumber.MIN`/`MAX`로.
+
+3. **`Any` 반환의 위험** — 타입 안전성 잃음. 일반화 비용 > 중복 비용일 때만 일반화.
+
+4. **이름과 책임의 동기화** — 리네임 시 함수명까지. 모호한 이름 (`Bank`)은 책임이 드러나는 이름으로.
+
+- **대표 인용:**
+  > 도메인 레이어는 view를 알면 안되지만, view에서는 domain을 알기 때문에 저는 InputView에서 바로 domain 모델을 만드는 방법을 선호하는 편입니다.
+  >
+  > — @laco-dev on `src/main/kotlin/lotto/LottoController.kt`
+
+  > 로또의 최솟값과 최댓값은 로또 번호가 가지는 명확한 개념이 아닐까요? 이 값을 공통으로 사용하게 되면, 로또 번호에게 협력을 하지 않고 모두 가져다 쓰는 문제가 될 수 있습니다.
+  >
+  > — @laco-dev on `src/main/kotlin/lotto/constant/LottoRule.kt`
+
+## 얻은 교훈
+
+- **InputView가 도메인 객체 반환 가능**. view → domain 의존은 허용되므로 InputView 안에서 도메인을 *조립*해 Controller에 *완성품*을 넘김.
+- **`LottoRule` 같은 상수 파일 = 도메인 비활성화**. 모든 곳이 상수를 가져다 쓰면 도메인 객체는 *수동적*. 도메인이 *자기 규칙을 소유*해야 협력이 생김.
+- **`Any` 반환 = 일반화의 함정**. 타입 안전성 잃으면 호출자가 캐스팅 부담. 미션 규모에서는 *중복 허용*이 더 안전.
+- **리네임은 *연관 이름까지*** — Grade → Rank 변경 시 `calculateGradePrize` → `calculatePrize`까지.
+- **`property + 동명 getter` 중복** = Kotlin에서 거의 항상 잘못된 패턴. property 하나면 됨.