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:

The unfinished half is sitting in the code as pseudocode. Open application/GameService.java and find execute(...):

private void execute(GameCommand command) {
    Game game = currentGame();
    command.execute(game);
    if (game.isGameOver()) {
        gameMonitor.gameCompleted(game);
        gameRepository.saveOutcome(game);
        // loop through all playerIds in the Game:
            // retrieved PlayerAccount from Repository
            // playerAccount.win(payout, playerOutcome)
            // repository.save(playerAccount)
    }
}

Turning those four comments into working code — test-first — is tonight's session. The good news: 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 — write the failing test first (this is the tracer bullet)

@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 — the smallest wiring that pays a winner

Now make it pass with the minimum. Add import ...domain.PlayerResult; and replace the four comments in execute():

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

Run the test → green. One winning path, wired. Notice what you did not do: no lose(), no push handling, no multi-player generalising. You only wrote enough to satisfy the one test — the TDD discipline of small, safe steps. (Verified: this passes, and the other 244 tests stay green.)

6 · The next reds — how tonight will actually unfold

Each of these is the next failing test that forces the next slice of code. This is the interleaving you'll do live — jot your prediction next to each:

So the likely arc tonight: win path (you've done it) → lose/push branch → multi-player → clean up the getFirst() fake and the leftover comments. You'll be one step ahead the whole way.

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.