Recently I do have many thoughts on where domain logic ends and where view starts. I know my position, but what is yours?
Here are few examples from 2 quite different (not) games: Shooting-Zombies, Typing-Letters-To-Kill-Approaching-Word-Represented-By-An-Alien-Ship
- player guesses a word and gets points
- player shoots an alien ship and gets points
- player shoots a zombie and gets points
- player does sth to a zombie and gets points
- player does sth to a sth and gets sth
- someone does sth to a sth and sth happens ;-)
- user via a mouse clicks DOM element and another DOM element’s html changes
- DOM element moves below X position and player looses points
- zombie approaches player too close and player looses points
- zombie position X is below scene lowest position Y and player looses points
- shot is made
- player tries to guess a word
- DOM element X position += 1
- bullet position X += 1
- What entities should a usecase have: generic or ones that actual game player uses?
- Is a “zombie” or a “word”, or “alien ship” just a PNG, and usecase should only contain generic name.. let’s say a “target”. Does it matter in the game(s)?
- Is X and Y position of an object important to a usecase, and should it be there; or only the view layer should know x,y and tell usecase: a.x is below b.x?
- Should view have any logic at all, and be fully usecase driven?
I personally like to start writing code using terms from the domain. And only – only – when it occurs a name should represent something more generic, and is worth to share some code, then I make it more generic, and introduce some reuse patterns.
Also when X and Y position is important to a usecase logic then I keep it in the usecase.
We can say both: “zombie approaches to close”, “div.zombie.pos_x < div.scene.bottom.pos_x” and both mean the same, but different abstraction
.. and time.. well time is a matter for another blog post.
If timing is important in the game.. (“round takes 60 second”, “player has 5 seconds to make a move”, “game presents solution for 2 seconds”, etc..) then should be considered as part of a domain too.
P.S. I assume in above there are 3 layers:
- Usecase having domain logic.
- View having browser/screen related things.
- Glue that glues both of them and is simple stupid to only pass one Usecase API call to one/many View API calls and vice versa