My Law #2: Business Logic .. and forming Use Cases

Posted on by

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
So I always wanted to be closer to the model part more than to other. It looked easy at first to create a Player class, it’s behaviour and data. And I was implementing high level business operations into the model, not the controllers layer nor the view.
class Player
  constructor: (@name, @age) ->

  throw_a_dice: () =>
    ...

  pick_a_card: () =>
    ...
.. but something was missing.. I discovered it just lately thanks to friends and possibly by waking up from a long 4-year hibernation that I was missing a representation of use cases in the system. TA daAA!

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)
It’s so obvious a use case must have a shape in the system somehow

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.

 

Share on Twitter