Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Models, Roles, Decorators, and Interactions -- A modest proposal for a toned done version of DCI that isn't as janky as Concerns.

Models, Roles, Decorators, and Interactions

A modest alternative to DCI that might be worth further thought

One of the problems with advancing the discussion on DCI is that we lack a comparable alternative pattern that has the same goals, but favors a low ceremony approach. The closest thing we have to that is Rails concerns, but they are more like distant relatives of the DCI concepts rather than first cousins, and that makes comparisions between the two approaches not especially fruitful.

I am considering the idea of experimenting with my own paradigm that captures the intent and purity of DCI, but with the convenience of concerns. Please note that this is just the starting point of a conversation, it is NOT a promise of comercially available cold fusion or a cure for cancer. It's just a gist with an idea on it I'd like to hear your thoughts on.

What if we had a top-level topology that was split into Models, Roles, Decorators, and Interactions?


A model is responsible for data access and persistence. It does not have logic of its own, apart from validations, and basic transformations that make its internal state more palatable for some other part of a system. Bonus points if these models are immutable, but it's not essential as long as consistency and safe access is maintained.

So for example, we might have a Person and Comment model, as shown below:

class Person < ActiveRecord::Base
  has_many :comments

class Comment < ActiveRecord::Base
  belongs_to :author, :class_name => "Person"

We might have some simple methods on these objects that make queries easier, but they wouldn't have any business logic in them. Models can be made up of other models via object composition, as long as those constraints were mainted.


A role is an object (potentially composite) that understands how to take specific actions that manipulate models, either directly or indirectly. It's not necessarily stateless, but its job is to collaborate with other objects, not to encapsulate data of its own. In that sense, a role is a transient thing that is meant to be constructed dynamically to complete an action, and then thrown out.

So in that sense, we might havve a Commenter role:

class Commenter
  def initialize(person)
    @person = person
  def recent_comments
    @person.comments.where("created_at > ?", 3.days.ago)
  def post_comment(text)
    @person.comments.create(:body => text)
  def update_comment(new_text)
    raise "Comment not owned by this person" unless == @person
    comment.update_attribute(:body, new_text)

This is a plain Ruby object that could perhaps live in app/roles. Like models, you can certainly build composite roles as needed, as long as their purpose is maintained.


A decorator is an object that takes a model and transforms it into something suitable for consumption by some other part of the system. This is used sometimes for presentation purposes, other times it is used for adapting data so that it be passed from one kind of API to another. In any case, it is a simple transformation of a model into a different representation: nothing more, nothing less.

So for this example, we might have something like this:

class CommentDecorator
  def initialize(comment)
    @comment = comment
  def to_json
    {:author =>, 
     :body   => comment.body,
     :date   => comment.created_at }.to_json 
  def to_html
    # use your imagination here

Again, composition is fine here: CommentDecorator could be a trivial facade that rests on top of lots of specific decorators for individual formats, if it'd help make it more modular and maintainable.


Here's where things get sticky. An interaction is not something that can be succinctly expressed in a general way, because it is by definition the code that forms the glue between the delivery mechanism (e.g. the Rails framework + the user's browser) and the application itself (the thing that understands the concept of a person, comment, and commenter). Because a generalization of interactions would be so abstract it would hardly mean anything at all, we must rely on common sense here. Complex interactions could be wrapped up in a network of objects, but we could work towards keeping interactions strictly procedural by pushing most of our substantial code into the Models, Decorators, and Roles.

That said, we could probably come up with plenty of sensible tactics and strategies for dealing with this part of our system, as long as we don't try to come up with the Grand Unified Theory of everything. By knowing what kind of application you want to build, and what kind of delivery mechanism you are using, it would probably be possible to build gems or libraries that help make certain kinds of interactions easier. However, rather than formalizing this concept, I'd prefer to leave it adhoc for now.


I personally like writing explicit class definitions that are plain old Ruby. But we could probably justify sprucing up these constructs within the context of particular frameworks. So I'd have no problem with some rails magic that'd give us something like this for roles and decorators:

class Commenter < ActiveSupport::Role
  concerns :person # this is a reuse of the word only, not the semantics.
  def recent_comments
    person.comments.where("created_at > ?", 3.days.ago)
  # ...

# usage

class CommentDecorator < ActiveSupport::Decorator
  decorates :comment
  # the view method and maybe a few other small helpers provided by decorator class
  def to_html
    view.content_tag(:p, comment.body)

# usage

I could care less whether this sugar used class inheritance or mixins, or if by some magic could be supported by composition (perhaps with a callback mechanism?). It's just an olive branch for those who love their sexy magic, but with the assumption that we can build it on top of a solid foundation.

What do you think?

It's just an idea, and since I just thought of it now, my code examples are as thin as the very DCI articles I've been critical of. I do plan to try out these ideas in a full scale application, but I'd like to get a sanity check on them first. They're not so much anything special or novel, they're just a collection of existing practices that I'm trying to group together so that we can discuss their interrelations. I'd love to hear what you think!

Copy link

verticonaut commented Dec 20, 2012

The Decorator pattern does not 'transform' or 'adapt' a model. A decorator - as it says - decorates an object. Meaning that is can modify the existing API or extend it (see You sample code does not implement a Decorator - rather a Formatter or Transformer. In order to implement a Decorator you would need to subclass from SimpleDelegator e.g. Then your implementation would extend the API - and the methods of the decorated comment would be still accessible.

E.g. Draper is an Gem to decorate you AR models. The models API ist still accessible, but may be modified. E.g. the accessor method updated_at would return a Time object, but the Decorator would overwrite the method so it would return a formatted Time object for use in a GUI. In addition there could be new extensions like e.g. edit_link that would render an edit link.

Copy link

practicingruby commented Dec 20, 2012

@galtenberg: Thanks for sharing your thoughts. The idea of me just revisiting DCI is actually part of the plan here, I only put forth MRDI because there are specific things about DCI that I do not understand (or am not convinced by) which I've been unable to get a clear answer to. (beware the link-bait title, the post is actually moderate in nature and the title is just satirical)

As for the issue of composition vs. mixins: Even if the latter work in practice, it seems to me as if we're almost creating a complex fix for the fundamental problem of inheritance, rather than sidestepping the issues entirely. I discuss this in a lot more detail over on the Reddit thread related to this proposal, and I would love to see what you think of the articles I link to in those comments. My fundamental opinion is that composition is conceptually simple and share-nothing by default, while mixins are fundamentally complex and share-everything by default. So in order to be convinced of the mixin approach, I want to see what value it adds that accounts for the extra cost in complexity.

As for contexts, I would love to see a nice example of them in practice, one that's deep enough to truly appreciate their value. The post from @zombiedev does not do that at all for me: it is far too simplistic for me to see the benefits.

If you've done DCI in the wild, I'd really love to see examples extracted from your work. Could you possibly share some of those?

Copy link

practicingruby commented Dec 20, 2012

@verticonaut Pretty much every word I've used here is potentially an overloaded term, and does not necessarily refer to some other thing that has been defined elsewhere. I'm open to renaming anything from this proposal.

When I say decorator, I mean it because these objects are meant to be used much in the same way that you might use Draper. I've just never personally seen the value in making full delegation automatic, and would actually count it as a special case (which should be avoided where possible) in the design style I'm advocating.

Thanks for pointing out the naming collision. I am mostly using MRDI not as a serious proposal for how we ought to do things, but instead as an experiment to help me understand (and perhaps help refine) the DCI concepts. If it ever did take on a life of its own, we'd need to think about these names much more carefully.

Copy link

lwoodson commented Dec 22, 2012

Part of my complaint with DCI is that I think its naming and concepts are overly abstract, probably even poorly chosen and open to all sorts of misinterpretation. 'Context' ooohkay, whats a context? A business context, usually for carrying out a one or more business operations spanning multiple models. Okay, why not call it business operation or operation or services ( 'Data', hmm, okay, sounds like a model. Why not call it model? Was there something in MVC that required models to be fat so that we need a different term to describe a skinny model? Not sure, okay, whatever. "Interaction", uh, yeah. Whats that? I'm not sure I know even now how to explain it. Lets say its the act of changing the way that a model may be interacted with in a given context. So a context-dictated change in the interface of an object. But I've yet to see any examples of such a change outside of the concept of a role and I can't really think of any. This company is a purchaser in this scenario and a seller in this scenario. A person is a felon in this scenario or a cop in this scenario. Why not simply call these roles?

In that regard, I like the spirit of your suggestion. Not sure if I agree with how all of that is accomplished.
Me personally, I wish it was called MRO or MRS (Model - Role - Operations|Services) and that as far as structuring within a rails project, that there were app/roles and app/operations or app/services directories.

Copy link

mech commented Jan 16, 2013

I think both has its place. Concern is good for use-cases like Taggable where every models has shared and similarly "change-together" piece of code.

When you comes to slightly complex business logic (which if you know business, its rules are ad-hoc and not tied down), you can use the DCI context to have its own isolated role-playing goodness.

Both has its place I feel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment