Michael Sokol

Data Context Integration, hands-on

If you aren’t familiar with DCI, I would suggest reading the well-written wikipedia page, right here.

It’s really easy to get started with DCI.

Your application can be seen as a network of communicating objects. Depending on the scenario, some objects are going to communicate with other objects. These objects represent a physical reality of the domain you are modeling.

The same object can be seen differently given the current scenario. A regular user of a website can be seen as a potential buyer if he clicks the little cart icon. Being a buyer gives more actions to the user. He can buy!

Let’s imagine your website has this kind of model for a user:

class User
  include YourFavoriteORM
  def login
    # User can log-in!
  end
end

(You probably don’t want to put any login method in your User model, but this just serves as an illustration)

You could add a buy method to your User class. However, DCI suggest that instead, you define a role:

class Role::Buyer
  
  def buy
    # Buyer can buy
  end
end

Instead of cluttering your model with a bunch of functionality that satisfies each and every possible scenario, making it a big monolithic structure, with possibly some ugly inheritance lying around, DCI suggest a logic separation of concern. Your object’s “kernel” has the bare minimum functionality. Whenever you need your object to know more, feed it with the appropriate role. When your object don’t need this extra knowledge, just take it off.

user = current_user
user.mixin Role::Buyer

user.buy

user.unmix Role::Buyer

Notice the Object#mixin and Object#unmix method. They are added by the mixology gem. A pretty nifty C extention to manage modules.