The Lay of the Land

Before you can pair with confidence, you need to open the project, run the tests, and know which way the architecture's arrows point. By the end you'll have a green suite (minus one deliberate red test) and a mental map of the codebase.

The win You'll open blackjack-ensemble-blue in IntelliJ with the right JDK, run all the tests with one shortcut, and correctly explain why the domain package imports nothing from Spring. That's the foundation every later lesson builds on.

1 · Open the project (once)

IntelliJ IDEA → Open → choose ~/Desktop/blackjack-ensemble-blue (the folder with pom.xml). IntelliJ detects Maven and imports it.
Trust the project when asked. Let the Maven import finish (watch the bottom status bar).
Set the JDK to 25. ⌘; (Project Structure) → Project → SDK → temurin-25; Language level → “25”. Also Settings → Build Tools → Maven → Importing/Runner should show a 25 JDK.

If it won't compile “release version 25 not supported” means IntelliJ is using JDK 21. Fix the Project SDK and the Maven Runner JDK to temurin-25. The repo needs 25 because pom.xml sets <java.version>25</java.version> — see the Repo Map.

2 · Run every test with one shortcut

Open HandValueAceTest (⌘O → type it). Put the caret in the class and press ⌃⇧R — IntelliJ runs it. To run the whole suite, right-click the src/test/java folder → Run 'All Tests', or use the committed run configs (top-right dropdown): All Tests, I/O-FREE Tests, I/O-Dependent & Framework Tests.

From the terminal (⌥F12) the README's way also works:

./mvnw verify

3 · Read the result — one test is red on purpose

You'll see ~68 passing and one failure:

GameServiceTest.placeBetsForPlayerAccountWithInsufficientBalanceThrowsException
  FAILURE: Expecting code to raise a throwable.

This is a feature, not a bug That red test is the ensemble's work-in-progress — a failing test left as the starting point for the next session (classic TDD). There's also a @Disabled test right below it (placeBetsReducesPlayerAccountBalance) marking where the work continues. We rebuild toward implementing these in the final lesson. For now: green everywhere else = your setup is correct.

4 · The shape of the codebase

This is a hexagonal (ports & adapters) app. Four ideas, one arrow:

  adapters  ──▶  application  ──▶  domain
 (web,          (GameService,      (Game, Hand, Card,
  console,       ports)             PlayerAccount, ...)
  repository)

Layer	Job	May depend on
domain	Pure Blackjack rules & state	nothing (no Spring!)
application	Use cases; drives the domain	domain
adapter.in / out	Web, console, DB, RNG	application + domain

Spend two minutes in the Project window (⌘1) expanding com.jitterted.ebp.blackjack. Notice how domain classes never import org.springframework…. That inward-only arrow is the whole game — full detail on the Repo Map.

5 · Quick recall — predict, then reveal

a. Which package is allowed to import org.springframework.web?

reveal

adapter.in.web

Only adapters touch frameworks. domain and application stay framework-free so they're fast to test.

b. GameService lives in application. May it call a class in domain?

reveal

Yes

Arrows point inward: application → domain is allowed. The reverse (domain → application) is forbidden.

c. The failing test in a freshly-cloned repo means my machine is broken. True or false?

reveal

False

It's the ensemble's deliberate red WIP test. Every other test passing is the signal your setup is right.

6 · Hands-on — prove your setup (I'll check it live)

Task · in IntelliJ + terminal

1. Run the whole suite. Confirm you see exactly one failure (placeBetsForPlayerAccountWithInsufficientBalanceThrowsException) and everything else green.

2. Using ⌘B (go to declaration), open Hand from inside HandValueAceTest. Then from Hand, find who calls value() — ⌥F7 (Find Usages).

3. Open GameService (⌘O). Look at its constructor parameters — all four are ports (interfaces from application.port). Write down, in one sentence, why the constructor takes interfaces instead of concrete classes.

Then run this from the repo root and tell me the last line:

./mvnw -q test -Dtest=WalletTest

reveal expected result

BUILD SUCCESS

WalletTest is a pure-domain test with no failing cases — it should pass on its own in well under a second.

Then say “done” — I'll quiz you on the four ports and the dependency rule, and we move to the domain core.

Primary source

Ted Young's jitterted.com / tedyoung.me and his talks on “Testable by Design.” On hexagonal architecture, the canonical piece is Alistair Cockburn's Hexagonal Architecture. For IntelliJ + Maven basics: JetBrains Maven support.

Import errors, wrong JDK, or the Project window looks different from mine? Ask me — I can read your pom.xml and run configs and tell you exactly what to click.