Mission.txt

# Mission/Goals

## Current Feature
- Add Betting support

NEXT:
=====

    [ ] Real database implementation of GameRepository using Spring Data JDBC

        [X] 1. Add dependencies: Spring Data JDBC, Flyway, Postgresql, Testcontainer
        [ ] 2. Create GameDbo (w/schemas)
               [X] Encode Card
               [X] Encode Deck
               [X] Encode Hand
               [ ] Create GameDbo
                    [X] isPlayerDone -- pick it up with fails to compile in GameDboTest
                    [X] Encode the Deck into a String property
                    [ ] (optional) Convert Encoder methods to non-static
                    [X] Decode GameDbo --> Game domain object
==>                 [ ] Encode/Decode Hand's ID -- "owned" by a HandFactory
               [ ] Consider converting to memento pattern
        [X] 3. Tests for mapping to/from Domain Object <-> DBO
        [X] Game: get rid of GameMonitor from Game (move into GameService)
        [X] 4. Write JdbcRepository tests to store/find DBOs
            [X] Create flyway DDL
            [X] Created JDBC repository interface
            [X] Tests for saving and ID assigned
            [X] Test for finding by ID
            [X] Test that all properties were stored
        [X] 5. Implement the translation to/from JDBC for the GameRepository interface
-->     [X] 6. Call GameRepository#save() after every command in GameService
            [ ] Make the InMemory version more like the real thing by always returning/storing different instances of Game
            **** DEEP COPY: do we want memento pattern?

Database:
Games:
Id : long
Deck : String -> String of encoded cards -> text
        AH,TC
PlayerHand : String -> String of encoded cards -> text
DealerHand : String -> String of encoded cards -> text
isPlayerDone : boolean

Reminder:  test that update does NOT assign a new ID


FUTURE:
=======

    [ ] Simulate a real database by returning different object instances for the same Game ID
        (this will force us to save changes to the game made inside the command methods in GameService)

    [ ] Use Event-Sourcing to store Games

## Bugs
- Both dealer cards are face up while game is in progress (hole card should be face down)

## Other Feature Options

3. Support multiple players (one dealer, multiple players)

## Done

    [X] Add intermediary: GameService, all commands/queries go through the service
    [X] Assign IDs to Game: have all GET/POST include that ID
        Next Step: in BlackjackController/GameService:
        [X] Add ID to POST URL in the HTML's action
        [X] Make all POST handlers use the incoming ID (from the URL)

        [X] Eventually, stop using the field `gameId` in the BlackjackController to hold onto a Game ID
        (push the constant out of GameService to the caller)

        [X] goal is to get rid of currentGame and replace it with gameFor(id)
        use the ID in redirect (returned from the POST) and as input from GET requests
            -> GET to /done needs game ID
    [X] Slight behavior change: consolidate doneView into gameView such that any hit of /game/{gameId}
            will show the correct state for "done" games

            * Question: do we end up with two endpoints (/game and /done) or a single endpoint of /game,
              which returns the appropriate template ("blackjack.html" or "done.html")
                * Upside of no /done endpoint is can't accidentally display invalid state (i.e., when the game is NOT done)

    [X] Try it again and see what happens?

        [X] Use the ID with a GameRepository (in-memory) to load/store the multiple games
                Refactor/extract from GameService
        [X] Create a proper Repository interface (PORT)