create domain model

[lexruee]

• create domain model
  • identify objects and relationships among them
  • abstract objects and identify classes
  • find responsibilities / roles for each class
  • etc...
• introduce unambiguous terms for objects
  • credits or earnings?
  • is a recorded session also a running session, boxing session?
• decide how to implement the rules for the achievements
  • json string based
  • pure object oriented

[lexruee]

It's not complicated as it looks like. Nevertheless, my UML skills are a little bit rusty.

[wanze]

Hi Alex, looks good :)

Achievements: With pure object oriented you mean that every Achievment is a separate object with its own logic for the check? I have the impression that this will lead to "too many" objects and also duplicated code.

Here is another apporach, trying to model a generic rules engine we can reuse also for the challenges:

There exist different kind of rules. Some are checking attributes of sport sessions, other could check conditions on the user object (e.g. number of partners). Each Rule-type is a class inheriting from "Rule". Now the achievment object somehow has do define: What Rule I want to evaluate my conditions against? Here, the object RuleDefinition comes into play. This object holds the data (for example in JSON) the Rule must evaluate against the User data, e.g. from the sport session.

Example: Achievment "Run more than 10km under 1 hour" defines a new RuleDefinition:

• rule would be AttributesRule, because we need to check the attributes
• data would hold the encoded data to evaluate: distance >= 10, time < 1

Advantages:

• Rules and RuleDefinitions are independent of achievments and can be reused for example for challenges
• Achievments could have multiple RuleDefinitions to check. This should work with a combination of two RuleDefinitions: Run more than 30km under 4 hours with at least 3 friends

Later on, a challenge can be formulated as one or multiple RuleDefinitions.

[lexruee]

@wanze

Achievements: With pure object oriented you mean that every Achievment is a separate object with its own logic for the >check? I have the impression that this will lead to "too many" objects and also duplicated code.

Do you mean objects or classes? Because in the OO approach we would have one class Achievement and each achievement is represented by a single instance.

The tricky part is the closure that is used for implementing the validation code for a game rule. If a game rule shares the same validation code, we just pass again the same closure.

Therefore there would be no duplicated code.

The main adavantage of this approach is that it can be easily tested because of object compostion and depedency injection principle.

The main drawback of course is that this solution is not dynamic compared with the 'condition as json string' approach and the issue to implement the challenges is not covered.

So here's the simple not complete oo approach :-)

@wanze You're current approach could work. It's not really KISS :-), but if it covers everything, I see no issues why we shouldn't go for your approach. In this approach we need a really well programmed and well tested condtion parser for complex condtions with the operators like and, or, not :-).

Besides that I like the idea to implement such a json condition parser.

Cheers, Alex

[wanze]

Thanks for the explanation, your model looks nice :) I first was thinking that each Achievment gets a separate class, inheriting from the Achievment base class. How would you store the data that a specific achievement must be compared against?