LESSON 0004 · The application layer · Blackjack Ensemble course

Lesson 0004 — Prep for tonight's ensemble (5pm)

Paying the Winners: wiring game-over payouts into the account

Last session you took money out of a PlayerAccount when a bet was placed. Tonight the ensemble does the mirror image: put money back in when the game is over. This lesson walks you through that exact change — test-first, starting from red — so you arrive already having driven it once.

1 · Where we are — money out, money in

Trace one round through GameService:

Open application/GameService.java and find execute(...). The ensemble has started the loop — but it finds the account and then does nothing with it:

if (game.isGameOver()) {
    gameMonitor.gameCompleted(game);
    gameRepository.saveOutcome(game);
    for (PlayerId playerId : game.playerIds()) {
        Optional<PlayerAccount> playerAccount =
                playerAccountRepository.find(playerId);   // ← found, but never credited
    }
    // still TODO: playerAccount.win(payout, outcome) + save(...)
}

The account is looked up and then dropped on the floor — no win, no save. Finishing that — test-first — is tonight's session. Every collaborator it needs already exists.

2 · The seam — three objects already built for you

You don't have to invent an API; you have to connect one. Three pieces are waiting:

// 1. The Game already computes each player's result:
List<PlayerResult> results = game.playerResults();

// 2. A PlayerResult knows who, what outcome, and how much:
result.playerId();   // PlayerId — who to look up
result.outcome();    // PlayerOutcome — WON? LOST? PUSH?
result.payout();     // int — outcome.payoff(bet), already computed

// 3. The PlayerAccount already accepts a win or a loss:
account.win(payout, outcome);  // enqueues PlayerWonGame → balance += payout
account.lose(outcome);         // enqueues PlayerLostGame → balance unchanged

3 · The payout maths (know this cold before 5pm)

PlayerOutcome carries a multiplier applied to the bet. It's the total returned, not the profit — and remember the bet was already subtracted when it was placed:

4 · RED — the failing test (this is the tracer bullet)

This test is already in your GameServiceTest — but marked @Disabled, so it isn't running. Delete the @Disabled to bring it back to life; it should go red. (If you're starting fresh, here it is in full — you'll also need import com.jitterted.ebp.blackjack.domain.StubDeck;.)

@Test
void whenPlayerWinsGameOverPaysPayoutIntoPlayerAccount() {
    PlayerAccountRepository accounts = PlayerAccountRepository.withNextId(9);
    PlayerAccount account = PlayerAccount.register("winner");
    account.deposit(50);
    accounts.save(account);
    GameService gameService =
            GameService.createForTest(new StubShuffler(), accounts);

    // player: QUEEN+TEN = 20, dealer: EIGHT+JACK = 18 → PLAYER_BEATS_DEALER
    Deck deck = new StubDeck(Rank.QUEEN, Rank.EIGHT, Rank.TEN, Rank.JACK);
    gameService.createGame(List.of(PlayerId.of(9)), new Shoe(List.of(deck)));
    gameService.placePlayerBets(List.of(new PlayerBet(PlayerId.of(9), Bet.of(11))));
    gameService.initialDeal();

    gameService.playerStands();          // game is now over, player won

    Optional<PlayerAccount> updated = accounts.find(PlayerId.of(9));
    assertThat(updated).get().extracting(PlayerAccount::balance)
            .isEqualTo(50 - 11 + 22);    // = 61
}

5 · GREEN — iterate playerResults(), not playerIds()

The started loop uses game.playerIds() — but an id alone can't tell you the payout, so you'd have to re-derive each player's outcome and bet. Don't. game.playerResults() hands you a PlayerResult that already carries playerId(), outcome(), and payout(). Swap the loop, add import ...domain.PlayerResult;, and credit the account:

for (PlayerResult result : game.playerResults()) {   // was: game.playerIds()
    playerAccountRepository.find(result.playerId())
            .ifPresent(account -> {
                account.win(result.payout(), result.outcome());
                playerAccountRepository.save(account);
            });
}

Run the test → green. That switch from playerIds() to playerResults() is the elegant move — tell, don't ask: the Game computed the result; the service just applies it. Notice what you did not do: no lose(), no push handling, no multi-player generalising — only enough to satisfy the one test (small, safe steps). (Verified: this passes; full suite 245 green.)

6 · The loss path — the subtle red that teaches where a decision belongs

Obvious next test: a player busts, so nothing is paid. You might reach for a balance assertion — but here's the trap:

for (PlayerResult result : game.playerResults()) {
    playerAccountRepository.find(result.playerId())
            .ifPresent(account -> {
                account.settle(result);          // domain decides win vs lose
                playerAccountRepository.save(account);
            });
}

So the likely arc tonight: win path (balance-driven) → win/lose decision (event-driven, ideally in the domain) → multi-player → clean up the getFirst() fake and the leftover comments.

Primary source

The behaviour behind the events — why win()/lose() enqueue rather than mutate — is in your own last session's learning record (event-sourced aggregate). For the money-in/money-out modelling, Ted Young's ensemble is the source: tedyoung.me. On driving from a failing test in small safe steps, Kent Beck, Test-Driven Development: By Example — the “red → green → refactor” and triangulation chapters.

Unsure how playerResults() figures out the outcome, or want to rehearse the multi-player red before 5pm? Ask me — I'll set up a second account and we'll predict two balances together.