Monday, December 2, 2013

Domain Modelling a.k.a. Object-Oriented Programming

Our industry created a new term for Object-Oriented Programming (combination of noun and behavior), it's called Domain Modelling. There's no problem with that, it gives us a richer vocabulary for something that closely resembles the real-world or the problem-at-hand. It will just be a source of confusion when we misuse the same vocabulary for something else.


Domain model models both nouns and behaviors. However, many thought that domain models are just all about nouns. This is where the confusion starts, if we remove the behavior from the domain model where do we place the behavior/business logic that acts on the noun? Should the domain model really just be a mere state repository?


With that confusion, a new term is coined to emphasize a domain model without behaviors, this kind of domain model is now called anemic domain model. And the domain model (that should inherently have behaviors in the first place) with behavior is now called rich domain model.


Had we not invented the term domain modelling; we might call the new OOP, that is an OOP with behavior, as Rich Object-Oriented Programming.


Modelling the real world is getting funny :-)


Here's the anemic computer model:

class Computer
{
    public int ComputerId { get; set; }

    public double Speed { get; set; }
    
    public double BaseSpeed { get; set; }
    
    public double MaxSpeed { get; set; }
}

Its behavior is in ComputerService.


class ComputerService
{
     public bool Overclock(Computer c, double multiplier)
     {
         bool safeToOverclock = false;
         
         double newSpeed = c.BaseSpeed * multiplier;
         if (newSpeed <= c.MaxSpeed) 
         {
             c.Speed = newSpeed;
             safeToOverclock = true;
         }
         
         return safeToOverclock;
     }
}


The problem with separating the behavior from its object is it's more difficult to identify the codes we can re-use. We tend to make duplicate codes if we don't know that there's an existing implementation already that act as an intelligent front-end(e.g. service) for the anemic domain model. Trying to discover the code we can re-use on a domain model(er.. rich domain model)? It's right there on the class! Just type dot character after the class instance, the model's behavior jumps out on intellisense/autocomplete, the model's intelligence is integrated right there on the model, a one-stop-shop feel.


This is the proper domain modelling for computer, this is now called a Rich Domain Model. A model with behavior, an object with behavior yay! Should we call this Rich OOP too?


class Computer
{
    public int ComputerId { get; set; }

    public double Speed { get; set; }

    public double BaseSpeed { get; set; }    

    public double MaxSpeed { get; set; }
    
    public bool Overclock(double multiplier)
    {
         bool safeToOverclock = false;
         
         double newSpeed = this.BaseSpeed * multiplier;
         if (newSpeed <= this.MaxSpeed) 
         {
             this.Speed = newSpeed;
             safeToOverclock = true;
         }
         
         return safeToOverclock;
     }
    
}



Let's practice Domain Model, er.. scratch that, let's practice Rich Domain Model! let's practice OOP!


Happy Computing! ツ