One of the interesting decisions is how to connect the plays with the game. Once you get a table full of possible object interactions there is no obvious connection yet between the Game object and the Plays. The obvious connection is that a Game is just a collection of ordered Plays. But when thinking about a game simulator environment - Plays create an very interesting dynamic. How might a simulator affect our object model. If we wanted to build a baseball simulator to be a proxy for the random chance and individual actions of players... that might lead to some very fun examples and possiblilties for Apps. How difficult would that be... pondering.

Fridays in November about 3pm CT
we are going to start up a
Baseball TDD Kata
You are welcome to join in. Twitch.TV/TDDAcademy

I can imagine an interaction like this: a Random Play Generator takes in the Game Situational Awareness (things such as the score, the base runners, the outs, the balls and strikes, etc.) and passes an initial play setup to the game Field Simulator, which also has the situational awareness but it's job is to process the initial play by calling the individual players to get their reactions and resolve the play to completion - then I supose it would call the Umpire to get the ruling on the Play. This would update the game situation and the next play would begin - this processing loop would continue until the game concluded.

Is this simulator what we are building - or is it just a simple score board, or the results of a game as recorded on a traditional scorecard? We have to decide.

One question I'm interested in is the Roster object - is it a [party-place-thing e.g Green Archtype] or is it a [moment interval e.g. Pink Archtype] object? What do you think?

One of the wonderful features of using index cards is the ability to create both the Green and Pink Roster cards and play around with them both. When we decide which archtype we think fits better we just place one on top of the other - this has the effect of a natural versioning system.

When creating object models one must decide on some rules or guidelines for distingusing between Entity Objects and Value Objects. In many cases the Description (Blue Archtype) is a Value Object. Value Objects have no conceptual identity. They should be treated as immutable. And in some cases just absorbed into the Party-Place-Thing (Green Archtype). So the Blue archtypes are typically trivial when modeling in color... it's the pink and green objects we want to foucus upon.

References:

GitHub: Starter Project - TheSwiftDojo

Java Modeling in Color with UML - Peter Coad

Object Modeling in Color

Domain-Driven Design by Eric Evans