Handling `player_id` and Integrating Context Object

[StefanSchade]

Implementation Plan for Handling player_id and Integrating Context Object

Objective

To establish a scalable and flexible mechanism for managing player identities and states across different layers of the application, specifically focusing on the navigation service and its interaction with the player's state.

Tasks

1. Establish PlayerState Repository

   • Description: Implement a repository interface within the domain's ports to abstract the handling of PlayerState entities. This includes creating a thread-safe in-memory implementation as an adapter.
   • Acceptance Criteria: Repository interface is defined with methods for managing PlayerState. An in-memory implementation is created, ensuring thread safety.

2. Implement Context Structure

   • Description: Design and implement a context structure to encapsulate the player_id and other cross-cutting concerns at the application's boundary. This context will be passed through to the domain layer as needed.
   • Acceptance Criteria: Context structure is capable of holding player_id and is extensible for future metadata. Successfully integrated into incoming adapters.

3. Modify Web Controller

   • Description: Update the web controller to extract the player_id from HTTP headers, encapsulate it within the context object, and pass it along to the use case layer.
   • Acceptance Criteria: Web controller extracts player_id and packages it into the context without issue. Context is passed correctly to the use case layer.

Currently unsure wether to pursue this step - right now, I did a stub implementation

4. Coordinate Use Cases
   • Description: Ensure use cases act as coordinators between the adapters and the domain services. The use case involving player movement should extract player_id from the context, retrieve the corresponding PlayerState from the repository, and invoke the navigation service with it.
   • Acceptance Criteria: Use case correctly handles the context, retrieves PlayerState based on player_id, and passes it to navigation_service. Navigation service operates as expected with the provided PlayerState.

Future Considerations

• Be prepared to extend the context object to accommodate authentication tokens or additional operational data.
• Monitor the flexibility and scalability of the repository and context implementations to ensure they meet the application's evolving needs.

[StefanSchade]

commit 03e16a75f6b566b811853bff57147a2c608b1fa7

Task 1

[StefanSchade]

commit 1ff9ea79c36aceeb825fddd88c525864387ac229

Task 2

• I did place RequestContext in the port layer to respect DDD principles and hexagonal architecture. It thus serves as a contract through which the application and domain layers can access request-specific data without directly coupling to web-specific details.
• The web adapter and the use case were adjusted acordingly
• For the moment I use a fixed player id.
• how new users end up in the repo (receiving their starting state) will have to be adressed later on.

[StefanSchade]

commit ff0aa7247a67df4a2e743db940920b3a6b84bd36

documents the benefits of the context

[StefanSchade]

commit 143acf18c01f7b3209bdc33a04e78f3a7148864e

connects use case and domain service - code compiles but should run into an error on execution since we do not set the initial player state. Confirmed by testing with postman

[StefanSchade]

commit 4ece10c98b86063a08a140295a3a8a0ade9b2c8c

initialize user state and in the process I had to adjust the repos slightly

[StefanSchade]

commit 3773fab48082b63058d0b7038ae8bfb446aa548d and ac16cf93e191fabf48098363ce6405875bf8abd8

where necessary since there was still a dummy implementation in move_player uc. Now the test with postman actually shows I am moving about as expected and get the right description.