As far as I remember I was always very eager on trying to transform natural world – it’s behaviour and information – into a computer. I always wanted to achieve two things:
- tell the computer how real world is modelled
- tell it in a way that a human can read and understand it
So the effect is
Implementing Business Logic of a domain is the most important and funny part to do
It has many impacts
- what is the model?
- what are the classes and how they look?
- how to persist data to a storage?
- how to deliver data to an app user and how to interact with the code
- where business logic should be implemented
class Player constructor: (@name, @age) -> throw_a_dice: () => ... pick_a_card: () => ...
It is very important to split your models into at least 2 parts, maybe even 3.
- “use cases”: a part where high level use cases, scenarios, algorithms, business logic is implemented (SelectingFirstPlayer, RollingADice, MakingAMove, PlayingMonopolyGame, ..)
- “base models”: a part where base classes are implemented with their basic methods attributes that can be reused in use cases (Game, Board, Player, Pawn, Dice, Move, ..)
- “storage”: a storage part (maybe, if it’s configuration would be too tight into base model classes, that it needs a separation)
I’m not yet sure what should be the scope of a use case. Using an example of a popular Monopoly board game, should a use case be “playing monopoly board game”, or only “throwing a dice and making a move”..
But I’m pretty sure all use cases must have a form in the system by being at least a class, that has this single responsibility: telling the whole algorithm of a use case in one place.