oh-my-oop 0.2.0

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

@@ -0,0 +1,691 @@
+# PR #35 — [블랙잭 2단계] 둘리 미션
+
+- **Reviewee:** [@hyemdooly](https://github.com/hyemdooly)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/35
+- **단계:** 2단계
+- **리뷰어:** [@galcyurio](https://github.com/galcyurio) — 1단계 #21 동일 reviewer
+- **라인 코멘트:** 13 스레드 — *PR 본문 자가 의문 3개 (judge 함수 분리 / DSL 빌더 / Domain ↔ View 경계) + reviewer 답변 3 자리 (Thread 1·2·3 PR 본문 인용으로 답변) + 고차함수 + Listener 콜백 vs UI 함수 인자 (onXxx 도메인 어휘) + MVC + 고차함수 위배 X (다만 code smell) + 예외 vs 재입력 + 외부글 (medium @elizarov 코틀린 예외 처리) + Domain layer 가장 테스트 쉬움 어휘 + DSL 활용 시점 (한 번 X / 테스트 fixture OK) + RankModel UI layer 한정 모델 + cards private + 일급 컬렉션 의미 보존 + Hand 정보를 Cards 에 위임 + 불필요한 캐스팅 + indent 깊이*
+- **양 단계 완성 reviewee** (1단계 #21 batch 19 분석 완료 + 2단계 #35 = batch 20 추가, 2023년 3월 코호트).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 3개 — 학습 적극성 모범
+
+PR 본문:
+
+> *"안녕하세요, 리뷰어님! 1단계 피드백을 반영하고 2단계 기능을 구현하였습니다. 제가 봐도 아직 코드가 부족하다고 생각하는데, 혼자 고민해도 어려워서 질문드립니다!*
+>
+> *1. 객체가 일을 해야한다고 생각해서 Player에 판단하는 기능을 넣었는데, judge 함수를 따로 다른 클래스에 빼는 것이 좋을까요?*
+> *2. 컨트롤러나 테스트코드에서 초기화하는 코드가 너무 복잡한 경우 DSL을 이용한 빌더를 작성해주는 것이 좋을까요? (Ex. Controller의 initBetInfo)*
+> *3. CardGame과 컨트롤러의 경계를 어떻게 지어야할지 감이 잘 안옵니다. (...) 저는 도메인에서 View의 함수를 사용하는 일은 피해야한다는 입장입니다! 도메인에서 View의 함수를 사용하는 것이, 도메인에서는 View에서 오는 함수인지 모른다고 할지라도 MVC에 위배되지 않는건가요?"*
+
+→ **PR 본문 자가 의문 3개 + 학생 자가 한계 인정 + 자가 의견 명시** (3번째 자가 의문에 *학생의 입장* 명시):
+
+#### 1.1. *학생 자가 의문 = 의견 + 의문 양립*
+
+- **judge 함수 위치**: 학생 *"객체가 일을 해야한다"* (Tell-Don't-Ask 인지) → *Player.judge 자가 적용* + *분리 의문*.
+- **DSL 빌더**: *복잡한 초기화 코드 자가 인식* → *DSL 대안 의문*.
+- **Domain ↔ View 경계 + 고차함수**: 학생 *"도메인에서 View의 함수를 사용하는 일은 피해야한다는 입장입니다!"* → *자가 의견 명시 + 다른 크루 의견 vs 자가 입장 비교*.
+
+#### 1.2. *PR 본문 답변 가시성 정공*
+
+reviewer 가 *PR 본문 자가 의문 3개에 각각 라인 코멘트로 답변* (Thread 1·2·3) = **PR 본문 자가 의문 답변 가능성 정공**. PR #139 (PR 본문 자가 의문 답변 X) 의 *반대 시점*.
+
+**MCP 룰 `pr-body-question-explicit-reviewer-quote` 후보** — *reviewer 가 PR 본문 자가 의문 인용 + 라인 코멘트 답변 = 가시성 정공*.
+
+PR #14·#106·#80·#82·#107·#46·#91·#11·#13·#18·#73 결의 *자가 의문 PR 본문* 강화.
+
+### 2. `enum FinalResult(val rate: Double)` 4 멤버 + Profit 책임
+
+```kotlin
+enum class FinalResult(val rate: Double) {
+    BLACKJACK_WIN(0.5), 
+    WIN(1.0), 
+    PUSH(0.0), 
+    LOSE(-1.0)
+}
+```
+
+→ **블랙잭 4 결과 + 수익률 멤버** = *PR #36·#87·#129·#138 결의 *enum 책임 강화* + *BLACKJACK_WIN 별도 멤버***. 
+
+다만 **`BLACKJACK_WIN = 0.5`** = *블랙잭 1.5배 vs 0.5배 도메인 룰 혼동* — *0.5배 = +0.5 추가 (1.5배 - 1.0배)*. **블랙잭 룰 와전 가능**.
+
+#### 2.1. *블랙잭 1.5배 도메인 룰*
+
+- *블랙잭 1.5배* = *베팅 × 1.5 받음* = *수익 = 베팅 × 0.5 (베팅 외 추가)*.
+- *학생 0.5* = *수익 (베팅 외 추가) 의미* → *수익 모델 정합* 단, *PR #36·#87·#138 의 `BLACKJACK_WIN(1.5)` 와 반대 시점 (베팅 × 1.5 = 총 받음)*.
+
+**MCP 룰 `blackjack-payout-vs-profit-model` 후보** — *총 받음 (1.5배) vs 순수익 (0.5배) 모델 양가*.
+
+PR #36·#87·#138 (총 받음 모델) vs PR #35 (순수익 모델). **트레이드오프**.
+
+#### 2.2. *PUSH (DRAW) 어휘*
+
+`PUSH` = *블랙잭 카지노 어휘* (DRAW 의 카지노 용어). PR #20·#28·#125·#147·#65·#92·#36·#87·#138 의 *DRAW* 어휘 와 **반대 시점** (카지노 도메인 어휘 정공).
+
+**MCP 룰 `domain-vocabulary-fidelity` 후보** — *PUSH vs DRAW = 도메인 어휘 정확성*.
+
+### 3. `Player.judge(dealer: Dealer): FinalResult` 다형성 — Tell-Don't-Ask + Player 자가 결정
+
+```kotlin
+class Player(hand: Hand, name: Name) : Participant(hand, name) {
+    private fun isBlackJackWin(dealer: Dealer): Boolean { ... }
+    private fun isWin(dealer: Dealer): Boolean { ... }
+    private fun isPush(dealer: Dealer): Boolean { ... }
+    private fun isLose(dealer: Dealer): Boolean { ... }
+
+    fun judge(dealer: Dealer): FinalResult = when {
+        isBlackJackWin(dealer) -> FinalResult.BLACKJACK_WIN
+        isLose(dealer) -> FinalResult.LOSE
+        isWin(dealer) -> FinalResult.WIN
+        isPush(dealer) -> FinalResult.PUSH
+        else -> FinalResult.LOSE
+    }
+}
+```
+
+→ **Player 자가 결정 (Tell-Don't-Ask 정공)** + **4 분기 private 메서드 분리** = *각 결과 자가 판단*. 
+
+reviewer (Thread 1):
+
+> *"지금 구현도 좋습니다. 🙂 다만 개인적으로는 객체 자체를 선언하는 것만으로도 의미가 있다고 생각해요. `Map<String, List<String>>`와 같이 사용하는 경우 각각의 타입이 어떤 의미인지를 알 수 없지만 클래스로 선언해두면 이름을 통해 역할을 드러낼 수 있기 때문이에요."*
+
+→ **reviewer 가 *현재 안 OK* + *별도 클래스도 의미 있음* 2 안 제시** = *학생 자가 선택 권유*. **MCP `oop_propose_alternatives` 핵심 가치 합류**.
+
+#### 3.1. *3 가지 트레이드오프*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| Player.judge (현재) | *Tell-Don't-Ask + Player 책임 명확* | *isWin/isLose/isPush/isBlackJackWin 4개 private 메서드 ↑* |
+| 별도 Judge/Referee 객체 | *판단 책임 분리 + 객체 자체 선언 의미* | *Judge ↔ Player ↔ Dealer 양방향 결합* |
+| State 패턴 (sealed) | *Tell-Don't-Ask + 다형성* | *State 추가 비용* |
+
+PR #87·#129·#138 결의 *Tell-Don't-Ask + 외부 객체 vs Participant 메서드* 트레이드오프 와 *반대 시점 정공*.
+
+### 4. `BetInfo(info: Map<Player, Bet>)` 일급 컬렉션 + `operator fun get`
+
+```kotlin
+data class BetInfo(val info: Map<Player, Bet>) {
+    operator fun get(player: Player): Bet? = info[player]
+}
+```
+
+→ **Bet Map 일급 컬렉션 + Kotlin operator overloading** = *betInfo[player]* 호출 가능. **Kotlin 어휘 자가 활용**.
+
+PR #36·#117·#138 결의 *Kotlin 어휘 자가 학습* 어휘 합류.
+
+다만 **`operator fun get` 반환 `Bet?` (nullable)** = *Bet 없을 시 null* → *호출자 nullable 처리 필요*.
+
+### 5. `data class Bet(amount: Int)` + min/max invariant
+
+```kotlin
+data class Bet(val amount: Int) {
+    init {
+        require(amount in MIN_AMOUNT..MAX_AMOUNT) { AMOUNT_RANGE_ERROR }
+    }
+
+    companion object {
+        private const val MIN_AMOUNT = 1000
+        private const val MAX_AMOUNT = 1000000
+    }
+}
+```
+
+→ **Bet 값 객체 + min/max invariant** — *블랙잭 베팅 1000원~1000000원 도메인 룰 자가 적용*. PR #138 (Money MIN_BETTING_MONEY = 1000) 결의 *최소 베팅액 정공* + *최대 베팅액 추가*.
+
+**MCP 룰 `domain-range-invariant` 후보** — *도메인 값 범위 invariant 강제*. PR #36·#138·#87 결.
+
+### 6. `GameResult.companion object.of(dealer, betInfos)` + `private constructor` 
+
+```kotlin
+class GameResult private constructor(val playersFinalResult: Map<Name, Int>) {
+    fun getDealerProfitResult(): Int = playersFinalResult.values.sum() * -1
+
+    companion object {
+        fun of(dealer: Dealer, betInfos: BetInfo): GameResult = ...
+    }
+}
+```
+
+→ **`private constructor` + companion object factory** = *생성자 외부 노출 X + factory 만 사용*. *Kotlin 어휘 자가 학습*.
+
+**MCP 룰 `private-constructor-with-static-factory` 후보**. PR #58 (data class private constructor copy 우회 함정) 결의 *반대 시점 (정공 활용)*.
+
+### 7. `getDealerProfitResult(): Int = playersFinalResult.values.sum() * -1` — 부호 반전 정공
+
+reviewer (Thread 7):
+
+> *"바로 모두 더해버리는건 어떨까요?*
+> *`fun getDealerProfitResult(): Int = playersFinalResult.values.sum() * -1`"*
+
+→ **Dealer 수익 = -Players 수익 합** (PR #36 `operator fun not()` 결의 정공). 학생 자가 적용.
+
+**MCP 룰 `dealer-profit-as-negated-player-sum` 후보** — *Dealer 수익 = 플레이어 합 부호 반전*. PR #36·#87·#129·#138·#139 누적 6+ PR.
+
+### 8. 추가 칭찬
+
+- Thread 5: *"ui layer에서만 쓰기 위한 모델 👍"* — `RankModel` UI layer 한정 모델. **PR #21 (1단계 SuitModel UI layer 미래 권유) 학생 자가 적용**. *학생 자가 학습 시간성 정공*.
+- Thread 12: 학생 *"이해했습니다, 감사합니다!"* — *Domain layer 가장 테스트 쉬움 어휘 학생 자가 수용*.
+
+## 못한 점 (설계 관점)
+
+### 1. Domain ↔ View 경계 — 고차함수 + Listener 정공 vs `show*`/`print*` 함수 인자
+
+reviewer (Thread 3 — PR 본문 3번째 자가 의문 답변):
+
+> *"고차함수를 받는 것으로는 MVC에 위배되지 않습니다. 위배되지는 않으나 `showXxx()`, `printXxx()`와 같은 이름이라면 code smell로 여겨집니다.*
+>
+> *조금 다르게 생각해보세요.*
+> *- as-is: domain에서 특정 상태가 되면, ui에서 넘어온 함수를 호출한다.*
+> *- to-be: domain에서 특정 상태가 되면, 해당 상태를 외부로 노출한다.*
+>
+> *쉽게 이야기하자면, 외부에서 domain 클래스에 Listener 또는 콜백 함수를 선언할 수 있도록 만들어보라는 뜻입니다. 또는 고차 함수로 받을 수도 있습니다. 또한 `showXxx()`와 같은 UI 중심의 이름이 아닌 `onXxx()` 형태로 domain 중심으로 이름이 지어져야 합니다."*
+
+→ **고차함수 자체 OK + UI 어휘 (`showXxx`) X + 도메인 어휘 (`onXxx`) OK**:
+
+#### 1.1. *학생 코드 검토*
+
+학생의 CardGame:
+```kotlin
+fun setBets(players: Players, onGetBet: (Name) -> Unit, getBet: () -> Bet): BetInfo = ...
+fun askGetMorePlayersCard(
+    players: Players,
+    onHit: (Name) -> Unit,
+    getAnswer: () -> Boolean,
+    onGetPlayerCard: (Player) -> Unit
+) { ... }
+fun getMoreDealerCard(dealer: Dealer, onHitDealer: () -> Unit) { ... }
+```
+
+→ **`onGetBet` / `onHit` / `onGetPlayerCard` / `onHitDealer` 도메인 어휘 자가 적용** = **reviewer 권고 (`onXxx` 형태) 정공**. 
+
+#### 1.2. *Listener vs 고차함수 vs 상태 노출 3 안*
+
+| 안 | 장점 | 단점 |
+|---|---|---|
+| 상태 노출 + 외부 polling (to-be 정공) | *완전 분리 + Domain → UI 의존 X* | *호출자가 매 상태 확인* |
+| Listener interface | *책임 그룹화 + onXxx 일관* | *Adapter 클래스 필요* |
+| 고차함수 (현재) | *호출자가 함수 참조 간결* | *람다 ↑ + 시그니처 분산* |
+
+PR #87·#137·#148·#36 결의 *Listener vs 고차함수 vs 상태 노출* 트레이드오프 합류.
+
+**MCP 룰 `domain-state-exposure-vs-callback` 강화** 누적 5+ PR (#137·#148·#36·#87·#35).
+
+#### 1.3. *외부글 X (다만 reviewer 어휘 풍부)*
+
+reviewer 의 *as-is / to-be 어휘 명시* = *학생 자가 학습 가시화*.
+
+### 2. `cards: LinkedList<Card>` private + 일급 컬렉션 의미 보존 (1단계 #21 결 재발)
+
+reviewer (Thread 4):
+
+> *"`cards`를 private으로 변경해주세요. 외부에서 `cards`를 곧바로 접근할 수 있기 때문에 의도치 않게 값을 변경할 수 있습니다. `cards`를 직접 접근해서 데이터를 꺼내므로 일급컬렉션으로 선언한 의미가 사라져버렸습니다. 조금 boilerplate code라고 느껴지더라도 간접적으로 변경하도록 만들어주세요. 정말 필요한 경우에만 `toList(): List<Card>`와 같은 함수에서 방어적 복사를 한 이후에 노출시켜주세요."*
+
+학생 자가 적용:
+
+```kotlin
+data class Cards(private val cards: LinkedList<Card>) {
+    ...
+    fun toList(): List<Card> = cards.toList()
+    ...
+}
+```
+
+→ **1단계 #21 (일급 컬렉션 + 위임 = 나쁜 습관) 결 강화** + **2단계 cards private 자가 적용** = *학습 시간성 정공*.
+
+**MCP 룰 `first-class-collection-delegation-pitfall` 강화** 누적 5+ PR (#21·#74·#108·#46·#35).
+
+### 3. 예외 vs 재입력 + 외부글 (medium @elizarov 코틀린 예외 처리)
+
+reviewer (Thread 6):
+
+> *"잘못된 입력이 들어온 경우 프로그램이 예외가 던져져서 강제 종료되기보다는 재입력을 받도록 만들어보세요.*
+>
+> *다음은 코틀린에서의 예외처리 방식입니다.*
+> *- 논리 오류일 때만 예외를 던지세요. (...)*
+> *- 논리 오류가 아니면 예외를 던지지 말고 null을 반환하세요.*
+> *- 실패하는 경우가 복잡해서 null로 처리할 수 없으면 sealed class를 반환하세요.*
+> *- 일반적인 코틀린 코드에서 `try-catch`를 사용하지 마세요.*
+>
+> *위 사항들의 자세한 설명은 아래 글을 읽어보세요. https://medium.com/@elizarov/kotlin-and-exceptions-8062f589d07"*
+
+→ **Kotlin 예외 처리 4 원칙 + 외부글 (Elizarov, Kotlin 핵심 개발자)**:
+
+#### 3.1. *4 원칙*
+
+1. *논리 오류 → 예외 (전역 catch + 리포팅)*.
+2. *비논리 오류 → null 반환*.
+3. *복잡 실패 → sealed class*.
+4. *일반 try-catch X*.
+
+→ **Kotlin 어휘 깊은 학습** = *PR #117·#138 (getOrNull 논리오류) 결의 *외부글 + 자가 학습* 강화*.
+
+**MCP 룰 `kotlin-exception-handling-strategy` 후보** — *4 원칙 + 외부글 (Elizarov)*. 누적 3+ PR (#129·#138·#35).
+
+### 4. DSL 빌더 활용 시점 — 한 번만 사용 X / 테스트 fixture O
+
+reviewer (Thread 2 — PR 본문 2번째 자가 의문 답변):
+
+> *"DSL은 주로 여러번 사용되는 public API를 조금 더 가독성있게 사용할 수 있도록 제공하는 별도의 public API라고 볼 수 있습니다. 지금과 같은 경우는 단 한번만 쓰이고 있고 제공하는 API가 bet() 하나라서 쓸 필요는 없어보입니다.*
+>
+> *별개로 테스트 코드 같은 경우에는 불필요한 정보를 제거하거나 fixture를 설정하는 경우 좋은 도구가 될 수 있습니다."*
+
+reviewer (Thread 11):
+
+> *"DSL은 외부에 드러낼 API를 조금 더 가독성있고 쉽게 작성할 수 있도록 새로운 언어를 만드는 개념이라고 볼 수 있습니다. 지금과 같은 경우에는 굳이 사용해서 얻는 이점이 없고 Builder 내부로 구현이 감추어지기 때문에 가독성도 오히려 좋지 않습니다. 이번 미션에서 DSL을 활용한다면 테스트 코드에서 불필요한 정보를 제거하거나 test fixture를 생성할 때 활용해보면 좋겠어요."*
+
+→ **DSL 활용 시점 명시**:
+
+#### 4.1. *3 가지 시점*
+
+| 시점 | 적합? |
+|---|---|
+| 한 번만 사용되는 public API | X — *간결한 함수로 충분* |
+| 여러 번 사용되는 public API + 가독성 | OK — *DSL 가치* |
+| 테스트 fixture 설정 | OK — *불필요한 정보 제거* |
+
+**MCP 룰 `dsl-applicability-criteria` 후보** — *DSL 사용 시점 트레이드오프*. PR #58·#137·#148 결의 *수업 적용 욕구 (Builder/DSL 의도 위반)* 결 합류.
+
+### 5. `Hand` 정보를 `Cards` 에 위임 — Tell-Don't-Ask
+
+reviewer (Thread 8):
+
+> *"정보를 가지고 있는 Cards에서 처리하도록 만들어보세요."*
+
+→ **정보 가진 곳 = 책임 위치** = Tell-Don't-Ask 정공. PR #138 (ParticipantCards 책임 이동) 결의 *학생 자가 적용*과 같은 어휘.
+
+**MCP 룰 `information-locator-as-responsibility` 후보** — *정보 가진 곳 = 책임 위치*.
+
+### 6. 불필요한 캐스팅 (Participants)
+
+reviewer (Thread 9): *"불필요한 캐스팅입니다."*
+
+→ **PR #21 (1단계 unnecessary cast via typed listOf) 결 재발** = *학습 시간성 한계*. **MCP 룰 `unnecessary-cast-via-typed-listOf` 강화** 누적 2+ PR (#21·#35).
+
+### 7. indent 깊이 (GameResult) — 함수 또는 지역 변수 분리
+
+reviewer (Thread 10): *"intent가 너무 깊습니다. 함수 또는 지역 변수로 분리해보세요."*
+
+→ **PR #129 (depth ≥2 자가 인식) 결과 같은 어휘** — *함수/지역 변수 분리*. **MCP 룰 `indent-depth-reduction` 후보** — *indent 깊이 = 함수/지역 변수 분리*.
+
+### 8. `Player.judge` private 메서드 4개 분기 중복 (isBlackJackWin/isWin/isPush/isLose)
+
+```kotlin
+private fun isBlackJackWin(dealer: Dealer): Boolean = when { !dealer.isBlackJack() && isBlackJack() -> true; else -> false }
+private fun isWin(dealer: Dealer): Boolean = when { !isBust() && dealer.isBust() -> true; !dealer.isBlackJack() && isBlackJack() -> true; ... }
+private fun isPush(dealer: Dealer): Boolean = ...
+private fun isLose(dealer: Dealer): Boolean = ...
+```
+
+→ **4 메서드 분기 중복** = *judge 의 when 분기와 동일 조건 반복*. *boolean 메서드 4개 = N 개 분기 평탄화 시 동일 조건 반복*.
+
+대안: **`judge` 안에서 직접 when 분기** (private 메서드 분리 X) — *함수 분리가 *추상화 의도 X*** (PR #117 `function-decomposition-creates-identity` 결).
+
+**MCP 룰 `boolean-method-decomposition-redundancy` 후보** — *Boolean 메서드 N개 분리 = when 분기 중복*. PR #117 결.
+
+### 9. `Player.isHit() = !isBust() && (hand.sum() != BLACKJACK_POINT)` — 21 정확 시 stop
+
+```kotlin
+override fun isHit(): Boolean = !isBust() && (hand.sum() != BLACKJACK_POINT)
+```
+
+→ **Player 21 정확 시 stop** = *PR #129·#138·#139 의 *21 시 hit 가능 (≤)* 와 **반대 시점 (21 시 stop)***. **블랙잭 룰 정공** — *21 = 블랙잭 = stop 자가 결정*.
+
+**MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 13+ PR ⭐⭐⭐. *21 시 hit X 자가 결정* 정공.
+
+### 10. `Dealer.isHit() = hand.sum() < HIT_STANDARD_POINT` (`< 17`) — 16 시 hit 정공
+
+```kotlin
+override fun isHit(): Boolean = hand.sum() < HIT_STANDARD_POINT  // < 17
+
+companion object {
+    private const val HIT_STANDARD_POINT = 17
+}
+```
+
+→ **`< 17` = 16 시 hit, 17 시 stop** = *블랙잭 표준 룰 정공*. PR #138 (16 ≤ hit) 결과 같은 의미. PR #129 (`<` 16 vs `<= 16`) 결의 *반대 시점*.
+
+**`HIT_STANDARD_POINT = 17`** 명명 = *17 부터 stop 의미 명확* — **PR #129·#138 의 `DEALER_MAX_SCORE = 16` 명명 양가성 (16 vs 17 기준) 반대 시점 정공**.
+
+**MCP 룰 `dealer-stand-threshold-naming` 후보** — *HIT_STANDARD vs MAX_SCORE 명명 정확성*.
+
+### 11. `CardGame.askGetMorePlayersCard` 람다 4개 인자 — 콜백 폭증
+
+```kotlin
+fun askGetMorePlayersCard(
+    players: Players,
+    onHit: (Name) -> Unit,
+    getAnswer: () -> Boolean,
+    onGetPlayerCard: (Player) -> Unit
+) { ... }
+```
+
+→ **람다 인자 4 개 = 콜백 폭증 + 시그니처 ↑**. PR #36·#87 결의 *Listener vs 고차함수 트레이드오프* 일관.
+
+대안: **PlayerActionListener interface** (PR #148 결):
+```kotlin
+interface PlayerTurnListener {
+    fun onHit(name: Name)
+    fun getAnswer(): Boolean
+    fun onGetPlayerCard(player: Player)
+}
+```
+
+**MCP 룰 `callback-lambda-explosion` 후보** — *람다 인자 ≥3 = Listener 후보*.
+
+### 12. `Bet` 의 `MAX_AMOUNT = 1000000` — 임의 도메인 룰
+
+```kotlin
+companion object {
+    private const val MIN_AMOUNT = 1000
+    private const val MAX_AMOUNT = 1000000
+    private const val AMOUNT_RANGE_ERROR = "배팅 금액은 1000원부터 1000000원까지 가능합니다."
+}
+```
+
+→ **`MAX_AMOUNT = 1000000` 임의 결정** — *블랙잭 도메인 룰 X*. **MCP 룰 `domain-rule-arbitrary-constant` 강화** 누적 2+ PR (#138·#35).
+
+### 13. `BetInfo.get(player): Bet?` nullable 반환 — null 처리 강제
+
+```kotlin
+operator fun get(player: Player): Bet? = info[player]
+```
+
+→ **Bet 없을 시 null 반환** = *호출자 nullable 처리 강제*. PR #138 *getOrNull = 논리오류 즉시 감지* 결 합류.
+
+**MCP 룰 `get-vs-getOrNull-exception-timing` 강화** 누적 2+ PR (#138·#35).
+
+### 14. `Cards.LinkedList<Card>` 자료구조 (1단계 #21 reviewer 권유 자가 적용)
+
+```kotlin
+data class Cards(private val cards: LinkedList<Card>) {
+    ...
+    constructor(cards: List<Card>) : this(LinkedList(cards))
+    fun pop(): Card = cards.pop()  // ← O(1)
+}
+```
+
+→ **PR #21 (1단계 LinkedList 권유) 학생 자가 적용** = *학습 시간성 정공*. **MCP 룰 `data-structure-choice-deck` 강화** 누적 5+ PR (#21·#58·#23·#26·#35).
+
+### 15. `Cards.sum()` Ace 분리 합산 — 2 단계 filterSum
+
+```kotlin
+fun sum(): Int {
+    var sum = filterSum { it != Rank.ACE }
+    sum = filterSum(sum) { it == Rank.ACE }
+    return sum
+}
+
+private fun filterSum(score: Int = 0, condition: (Rank) -> Boolean): Int {
+    var sum = score
+    cards.toList().filter { condition(it.rank) }.forEach {
+        sum += it.rank.getScore(sum)
+    }
+    return sum
+}
+```
+
+→ **Ace 분리 합산 + filterSum 일반화** — *PR #21 (1단계 `Cards.sum`) 결 동일* + *2 단계 filterSum 함수 분리* = *PR #117 (function-decomposition-excess) 결의 *반대 시점 (의미 있는 추출)***.
+
+**MCP 룰 `ace-bonus-multi-pass-vs-math-formula` 후보** — *2 단계 filterSum vs 수학적 단일 식 (PR #117 결)*.
+
+### 16. `GameResult` 의 `private constructor` — 외부 생성 차단
+
+§6 참조. *Kotlin 어휘 자가 활용 정공*.
+
+### 17. `CardGame.bulidPlayers` 오타 (`buildPlayers` 가 정상)
+
+```kotlin
+private fun bulidPlayers(names: Names) = buildList { ... }
+```
+
+→ **오타 `bulidPlayers`** (build → bulid). PR #87 (Aginst), PR #117·#139 (isBackJack) 결 합류. **MCP 룰 `english-spelling-naming` 강화** 누적 3+ PR.
+
+### 18. `pickTwice` `setUp` `setDealer` `setPlayers` 명명 양가
+
+- `setUp(names)`: *Participants 초기화 (반환 = Participants)*. `set` prefix = *Java getter/setter 어휘*. *코틀린 어휘 양가*.
+- `setDealer()`, `setPlayers(names)`: *Dealer/Players 인스턴스 *생성 (`Dealer(...)` `Players(...)`)*. *`create*` 또는 `make*` 가 정공*.
+
+대안:
+- `setUp` → `initialize` / `start`.
+- `setDealer` → `createDealer`.
+- `setPlayers` → `createPlayers`.
+
+**MCP 룰 `set-prefix-vs-create-prefix` 후보** — *Java setter 어휘 vs Kotlin 어휘*.
+
+### 19. `RankModel` UI layer 한정 모델 — PR #21 미래 권유 자가 적용
+
+1단계 #21 reviewer (Thread 12): *"조금 더 고도화해본다면 ui layer에서만 사용하는 SuitModel을 만들고 해당 클래스에서 UI를 제공하도록 만드는 방법도 있습니다. 이 방식은 이번 미션에서는 적용하지 않아도 좋지만 추후 안드로이드에서 자주 쓰이는 방식이니 미리 인지해두시면 좋겠어요."*
+
+→ 학생 2단계 #35 자가 적용 (RankModel) = **학습 시간성 정공**. reviewer 칭찬 (Thread 5).
+
+**MCP 룰 `ui-layer-model-separation` 강화** 누적 2+ PR (#21·#35).
+
+### 20. CardGame ↔ Controller 경계 학생 자가 학습 + Domain layer 가장 테스트 쉬움 어휘
+
+reviewer (Thread 12):
+
+> *"각 layer의 역할을 침범하지만 않는다면, 지금처럼 최대한 domain layer로 관련 로직을 옮겨주면 좋습니다. 그 이유는 domain layer가 가장 테스트하기 쉬운 layer이기 때문입니다.*
+>
+> *presentation layer에 해당하는 controller에 대한 테스트 코드와 ui layer에 해당하는 InputView, OutputView에 대한 테스트 코드를 작성해야 한다고 생각해보면 왜 domain layer로 옮겨야 하는지 이해하기 쉬울거에요."*
+
+학생: *"이해했습니다, 감사합니다!"*
+
+→ **Domain layer 가장 테스트 쉬움 어휘** = **PR #87 (테스트 = 객체 설계 명세서) + PR #129 (테스트 가능성 = 객체 설계 지표) 결 합류**.
+
+**MCP 룰 `domain-layer-testability-priority` 후보** — *Domain layer = 가장 테스트 쉬움 → 로직 우선 위치*.
+
+### 21. `Participant.isBlackJack() = (hand.size == 2) && (hand.sum() == BLACKJACK_POINT)` — 정공
+
+```kotlin
+fun isBlackJack(): Boolean = (hand.size == 2) && (hand.sum() == BLACKJACK_POINT)
+```
+
+→ **블랙잭 = 초기 2장 + 21점 정공** = PR #138·#129·#36·#87 결의 *isBlackJack* 룰 정공.
+
+다만 **PR #139 reviewer (woowahan-dino) Thread 3 *short-circuit evaluation*** 어휘 적용:
+- `(hand.size == 2) && (hand.sum() == BLACKJACK_POINT)` = *hand.size cheap 먼저 + sum 계산 비용 뒤* = **short-circuit 정공**.
+
+PR #139 결 강화.
+
+### 22. `CardGame.getMoreDealerCard` while 루프 — 재귀 X
+
+```kotlin
+fun getMoreDealerCard(dealer: Dealer, onHitDealer: () -> Unit) {
+    while (dealer.isHit()) {
+        onHitDealer()
+        dealer.pick(cardPack)
+    }
+}
+```
+
+→ **while 루프 (재귀 X)** = *PR #138 (Player.choice 재귀, ShuffledDeck.pop 재귀) 결의 *반대 시점 (명령형)***. 
+
+reviewer 명시 X — *현재 안 OK*. 
+
+### 23. `getName` 으로 넘기지 말고 UI layer 재입력 처리
+
+reviewer (Thread 13):
+
+> *"`getName()`으로 넘기기보다는 UI layer에서 재입력을 받도록 처리하고 domain layer에서는 올바른 입력만 들어오도록 만들어보세요. domain에서는 ui를 알지 못해야하지만 ui 에서는 domain을 알아도 됩니다. 이 점을 활용해보세요."*
+
+→ **재입력 = UI layer 책임 + Domain layer = 올바른 입력만 받음** = *MVC 정공*. **MCP 룰 `model-view-dependency-direction` 강화** 누적 10+ PR ⭐⭐⭐.
+
+#### 23.1. *대안 (UI ↔ Domain 의존 방향)*
+
+| 안 | Domain | UI |
+|---|---|---|
+| Domain 가 재입력 (학생 초안) | *Domain 이 invalid input + 재입력 + 검증 모두* | *수동적* |
+| UI 재입력 + Domain 검증 (정공) | *Domain 은 valid 만 받음* | *UI 가 재입력 루프 + 검증 호출* |
+
+**MCP 룰 `retry-loop-locator-ui-vs-domain` 후보** — *재입력 위치 = UI*.
+
+## 리뷰어 의견 요지
+
+- **PR 본문 자가 의문 3개에 라인 코멘트로 답변 (Thread 1·2·3)** — *judge 분리 / DSL 빌더 / Domain↔View 경계*.
+- **judge 함수 = 현재 OK + 객체 자체 선언 의미 (Map<String, List<String>> vs 클래스)** — *2 안 제시 + 학생 자가 선택*.
+- **DSL 활용 시점 = 여러 번 사용 + 가독성 + 테스트 fixture** — *한 번만 사용 X*.
+- **고차함수 + Listener 정공 + `onXxx` 도메인 어휘 + `showXxx` code smell** — *as-is/to-be 어휘*.
+- **Domain ↔ View 경계 = 상태 노출 정공 (외부 polling)** — *Listener 또는 고차함수 + 도메인 어휘*.
+- **cards private + 일급 컬렉션 의미 + toList 방어적 복사** — *1단계 #21 결 재발*.
+- **Kotlin 예외 처리 4 원칙 + 외부글 (Elizarov)** — *논리 오류 / null / sealed / try-catch X*.
+- **DealerProfit = playerProfits.sum() * -1** — *부호 반전 정공*.
+- **정보 가진 곳 = 책임 위치 (Hand → Cards)** — *Tell-Don't-Ask*.
+- **불필요한 캐스팅** — 1단계 결 재발.
+- **indent 깊이 = 함수/지역 변수 분리**.
+- **DSL 외부 드러낼 API + Builder 내부 구현 감춤**.
+- **Domain layer 가장 테스트 쉬움 = 로직 우선 위치**.
+- **getName 으로 넘기지 말고 UI layer 재입력 + Domain 은 valid 만**.
+- **RankModel UI layer 한정 모델 칭찬 (1단계 #21 미래 권유 자가 적용)**.
+
+## 대표 인용
+
+> [hyemdooly PR 본문]
+> *"객체가 일을 해야한다고 생각해서 Player에 판단하는 기능을 넣었는데, judge 함수를 따로 다른 클래스에 빼는 것이 좋을까요?"*
+
+→ **학생 자가 의문 = Tell-Don't-Ask 인지 + 분리 의문 양립**.
+
+> [hyemdooly PR 본문]
+> *"저는 도메인에서 View의 함수를 사용하는 일은 피해야한다는 입장입니다! 도메인에서 View의 함수를 사용하는 것이, 도메인에서는 View에서 오는 함수인지 모른다고 할지라도 MVC에 위배되지 않는건가요?"*
+
+→ **학생 자가 의견 명시 + 의문 양립** — *자가 입장 + 의문 표현 모범*.
+
+> [galcyurio Thread 1]
+> *"지금 구현도 좋습니다. 🙂 다만 개인적으로는 객체 자체를 선언하는 것만으로도 의미가 있다고 생각해요. `Map<String, List<String>>`와 같이 사용하는 경우 각각의 타입이 어떤 의미인지를 알 수 없지만 클래스로 선언해두면 이름을 통해 역할을 드러낼 수 있기 때문이에요."*
+
+→ **`Map<String, List<String>>` 타입 누수 vs 클래스 선언 의미** = *PR #36·#117 (tuple 누수) 결의 강화*.
+
+> [galcyurio Thread 3]
+> *"고차함수를 받는 것으로는 MVC에 위배되지 않습니다. 위배되지는 않으나 `showXxx()`, `printXxx()`와 같은 이름이라면 code smell로 여겨집니다. (...) 외부에서 domain 클래스에 Listener 또는 콜백 함수를 선언할 수 있도록 만들어보라는 뜻입니다. (...) `showXxx()`와 같은 UI 중심의 이름이 아닌 `onXxx()` 형태로 domain 중심으로 이름이 지어져야 합니다."*
+
+→ **고차함수 자체 OK + `onXxx` 도메인 어휘 정공** + **as-is / to-be 어휘**. **MCP 핵심 가치 합류**.
+
+> [galcyurio Thread 6]
+> *"논리 오류일 때만 예외를 던지세요. (...) 논리 오류가 아니면 예외를 던지지 말고 null을 반환하세요. (...) 실패하는 경우가 복잡해서 null로 처리할 수 없으면 sealed class를 반환하세요. (...) 일반적인 코틀린 코드에서 `try-catch`를 사용하지 마세요."*
+
+→ **Kotlin 예외 처리 4 원칙 + 외부글 (Elizarov, Kotlin 핵심 개발자)** — *깊은 어휘 인용*.
+
+> [galcyurio Thread 12]
+> *"각 layer의 역할을 침범하지만 않는다면, 지금처럼 최대한 domain layer로 관련 로직을 옮겨주면 좋습니다. 그 이유는 domain layer가 가장 테스트하기 쉬운 layer이기 때문입니다."*
+
+→ **Domain layer = 가장 테스트 쉬움 어휘** = *PR #87·#129 결 합류*.
+
+> [galcyurio Thread 13]
+> *"domain에서는 ui를 알지 못해야하지만 ui 에서는 domain을 알아도 됩니다. 이 점을 활용해보세요."*
+
+→ **MVC 의존 방향 정공 어휘** — *UI → Domain OK, Domain → UI X*.
+
+## 얻은 교훈 (보편)
+
+1. **PR 본문 자가 의문 3개 + reviewer 가 PR 본문 인용 + 라인 코멘트 답변** — *PR 본문 자가 의문 답변 가시성 정공*. **MCP 룰 `pr-body-question-explicit-reviewer-quote` 후보**. PR #139 (PR 본문 자가 의문 답변 X) 반대 시점.
+
+2. **객체 자체 선언 의미 (Map<String, List<String>> vs 클래스)** — *타입 누수 vs 도메인 객체*. **MCP 룰 `tuple-leak-vs-domain-dto` 강화** 누적 4+ PR.
+
+3. **DSL 활용 시점 (여러 번 + 테스트 fixture)** — *한 번만 사용 X*. **MCP 룰 `dsl-applicability-criteria` 후보**.
+
+4. **고차함수 + `onXxx` 도메인 어휘 정공 + as-is / to-be 어휘** — *고차함수 자체 OK + UI 어휘 X*. **MCP 룰 `domain-state-exposure-vs-callback` 강화** 누적 5+ PR.
+
+5. **Kotlin 예외 처리 4 원칙 + 외부글 (Elizarov)** — *논리 오류 / null / sealed / try-catch X*. **MCP 룰 `kotlin-exception-handling-strategy` 후보** 누적 3+ PR.
+
+6. **Dealer 수익 = Players 합 부호 반전** — *PR #36 결*. **MCP 룰 `dealer-profit-as-negated-player-sum` 강화** 누적 6+ PR.
+
+7. **정보 가진 곳 = 책임 위치 (Hand → Cards)** — *Tell-Don't-Ask 정공*. **MCP 룰 `information-locator-as-responsibility` 후보**.
+
+8. **불필요한 캐스팅 1단계 → 2단계 재발** — *학습 시간성 한계*. **MCP 룰 `unnecessary-cast-via-typed-listOf` 강화** 누적 2+ PR.
+
+9. **indent 깊이 = 함수/지역 변수 분리** — **MCP 룰 `indent-depth-reduction` 후보**.
+
+10. **Boolean 메서드 N개 분리 = when 분기 중복** — *4 boolean 메서드 vs 1 when*. **MCP 룰 `boolean-method-decomposition-redundancy` 후보**.
+
+11. **RankModel UI layer 한정 모델 (PR #21 1단계 미래 권유 자가 적용)** — *학습 시간성 정공*. **MCP 룰 `ui-layer-model-separation` 강화** 누적 2+ PR.
+
+12. **Domain layer = 가장 테스트 쉬움 = 로직 우선 위치** — *PR #87·#129 결 합류*. **MCP 룰 `domain-layer-testability-priority` 후보**.
+
+13. **UI 재입력 + Domain 검증 = MVC 의존 방향 정공** — *Domain → UI X, UI → Domain OK*. **MCP 룰 `retry-loop-locator-ui-vs-domain` 후보**.
+
+14. **블랙잭 0.5 vs 1.5 모델 (순수익 vs 총 받음)** — *블랙잭 1.5배 정확성 양가성*. **MCP 룰 `blackjack-payout-vs-profit-model` 후보**.
+
+15. **PUSH vs DRAW 도메인 어휘** — *카지노 블랙잭 정확 어휘*. **MCP 룰 `domain-vocabulary-fidelity` 후보**.
+
+16. **Player 21 정확 시 stop 자가 결정 (`!= BLACKJACK_POINT`)** — *블랙잭 룰 정공*. PR #129·#138·#139 의 *21 시 hit 가능* 반대 시점. **MCP 룰 `blackjack-rule-fidelity-comparison` 강화** 누적 13+ PR ⭐⭐⭐.
+
+17. **Dealer 16 시 hit / 17 시 stop (`< 17`)** — *블랙잭 표준 룰 정공*. **MCP 룰 `dealer-stand-threshold-naming` 후보**.
+
+18. **private constructor + companion object factory** — *Kotlin 어휘 정공*. **MCP 룰 `private-constructor-with-static-factory` 후보**.
+
+19. **`set` prefix vs `create` prefix** — *Java setter 어휘 vs Kotlin 어휘*. **MCP 룰 `set-prefix-vs-create-prefix` 후보**.
+
+20. **블랙잭 베팅 1000-1000000 임의 도메인 룰** — *임의 max 값*. **MCP 룰 `domain-rule-arbitrary-constant` 강화** 누적 2+ PR.
+
+21. **Ace 분리 합산 + filterSum 함수 분리 (의미 있는 추출)** — *PR #117 function-decomposition-creates-identity 반대 시점*. **MCP 룰 `ace-bonus-multi-pass-vs-math-formula` 후보**.
+
+22. **2 reviewer (galcyurio + woowahan-dino) 의 *delegation 어휘 차이*** — *PR #21 galcyurio = 위임 = 나쁜 습관 / PR #117 woowahan-dino = delegation 권유* (이미 batch 19 발견).
+
+## 얻은 교훈 (도메인)
+
+1. **블랙잭 PUSH (DRAW의 카지노 어휘)** — *도메인 어휘 정확성*.
+
+2. **블랙잭 베팅 범위 (1000원~1000000원 임의)** — *최소/최대 invariant + 임의 값*.
+
+3. **`BLACKJACK_WIN = 0.5` (순수익 모델)** — *블랙잭 1.5배 = 베팅 × 1.5 받음 = 수익 = 베팅 × 0.5*. PR #36·#87·#138 의 *총 받음 모델* 반대 시점.
+
+4. **Player 21 정확 시 stop 자가 결정** — *블랙잭 룰 정공*. PR #129·#138 의 *21 시 hit (≤)* 반대 시점.
+
+5. **Dealer 16 시 hit / 17 시 stop (`HIT_STANDARD_POINT = 17`)** — *명명 정확성*.
+
+6. **Ace 1↔11 양가성 + filterSum 2 단계 합산** — *PR #21 1단계 결 유지*.
+
+7. **카드 중복 invariant 양쪽 검증 (init + add)** — *PR #21 1단계 결 유지*.
+
+## MCP 룰 후보 신규 + 강화 (PR #35)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `pr-body-question-explicit-reviewer-quote` | 신규 | 1 (#35) — PR #139 반대 시점 |
+| `dsl-applicability-criteria` | 신규 | 1 (#35) |
+| `domain-state-exposure-vs-callback` | 강화 | 5+ (#137·#148·#36·#87·#35) |
+| `kotlin-exception-handling-strategy` | 신규 | 3+ (#129·#138·#35) |
+| `dealer-profit-as-negated-player-sum` | 강화 | 6+ (#36·#87·#129·#138·#139·#35) |
+| `information-locator-as-responsibility` | 신규 | 1 (#35) |
+| `indent-depth-reduction` | 신규 | 1 (#35) |
+| `boolean-method-decomposition-redundancy` | 신규 | 1 (#35) |
+| `ui-layer-model-separation` | 강화 | 2+ (#21·#35) |
+| `domain-layer-testability-priority` | 신규 | 1 (#35) |
+| `retry-loop-locator-ui-vs-domain` | 신규 | 1 (#35) |
+| `blackjack-payout-vs-profit-model` | 신규 | 1 (#35) |
+| `domain-vocabulary-fidelity` | 신규 | 1 (#35) |
+| `blackjack-rule-fidelity-comparison` | 강화 | 13+ ⭐⭐⭐ |
+| `dealer-stand-threshold-naming` | 신규 | 1 (#35) |
+| `private-constructor-with-static-factory` | 신규 | 1 (#35) |
+| `set-prefix-vs-create-prefix` | 신규 | 1 (#35) |
+| `domain-rule-arbitrary-constant` | 강화 | 2+ (#138·#35) |
+| `ace-bonus-multi-pass-vs-math-formula` | 신규 | 1 (#35) |
+| `first-class-collection-delegation-pitfall` | 강화 | 5+ |
+| `unnecessary-cast-via-typed-listOf` | 강화 | 2+ (#21·#35) |
+| `english-spelling-naming` | 강화 | 3+ |
+| `callback-lambda-explosion` | 신규 | 2+ (#35·#36) |
+| `tuple-leak-vs-domain-dto` | 강화 | 4+ |
+| `data-structure-choice-deck` | 강화 | 5+ |
+
+## 메타 어휘 (13 reviewer + MCP 핵심 가치 합류 정점 유지)
+
+- ***PR 본문 자가 의문 3개 + reviewer 가 PR 본문 인용 + 라인 코멘트 답변*** — galcyurio PR #35 — **PR 본문 자가 의문 답변 가시성 정공** = *PR #139 (PR 본문 답변 X) 반대 시점*.
+- ***`Map<String, List<String>>` vs 클래스 선언 의미*** — galcyurio PR #35 — *Tuple 누수 vs 도메인 객체 어휘*.
+- ***as-is / to-be 어휘*** — galcyurio PR #35 — *Domain → UI 호출 (as-is) vs 상태 노출 (to-be)* + *onXxx 도메인 어휘*.
+- ***Kotlin 예외 처리 4 원칙 + 외부글 (Elizarov)*** — galcyurio PR #35 — *Kotlin 핵심 개발자 외부글 인용*.
+- ***Domain layer 가장 테스트 쉬움*** — galcyurio PR #35 — *PR #87·#129 (테스트 = 객체 설계 명세서) 결 합류*.
+- ***UI 재입력 + Domain 검증 = MVC 의존 방향 정공*** — galcyurio PR #35 — *Domain → UI X, UI → Domain OK*.
+- ***DSL 활용 시점 명시 (여러 번 + 테스트 fixture)*** — galcyurio PR #35 — *한 번만 사용 X*.
+
+→ **13 reviewer + MCP 핵심 가치 어휘 합류 정점 유지**. **galcyurio (PR #21 + #35) 어휘 합류 = 메타 어휘 깊이 정점**.
+
+## 비교 (PR #21 → #35 진화 — 사족 X, 안티패턴 명시만)
+
+- **1단계 #21 자가 의문 0개 → 2단계 #35 PR 본문 자가 의문 3개** — *학생 자가 의문 정점 진화*.
+- **1단계 #21 일급 컬렉션 + 위임 권유 → 2단계 #35 cards private 자가 적용** — *학습 시간성 정공*.
+- **1단계 #21 LinkedList 권유 → 2단계 #35 LinkedList 자가 적용** — *학습 시간성 정공*.
+- **1단계 #21 SuitModel UI layer 미래 권유 → 2단계 #35 RankModel UI layer 자가 적용** — *학습 시간성 정공*.
+- **1단계 #21 불필요한 캐스팅 → 2단계 #35 불필요한 캐스팅 재발** — *학습 시간성 한계*.
+- **1단계 #21 단순 PR 본문 → 2단계 #35 자가 의문 3개 + 자가 의견 명시** — *학생 자가 의문 진화*.
+
+→ *진화 비교 = 사족 아님 (안티패턴 코드 위치 명시)* + *학생 자가 학습 정점 + 일부 한계 (캐스팅 재발)*.