My notes on the DCI architecture

March 04, 2013

My notes on The DCI Architecture:

The fundamental problem solved by DCI is that people have two different models in their heads of a single, unified thing called an object. They have the what-the-system-is data model that supports thinking about a bank with its accounts, and the what-the-system-does algorithm model for transferring funds between accounts. Users recognize individual objects and their domain existence, but each object must also implement behaviors that come from the user's model of the interactions that tie it together with other objects through the roles it plays in a given Use Case.

... the mapping between the role view and data view—is also part of the user cognitive model. We call it the Context of the execution of a Use Case scenario.

So for now, my "how to DCI" would consist of:

I even think this can be further reduced to a function. So for the next few paragraphs I will check if there is a difference to a bare function.

The more dynamic operations related to the Use Case scenario come from the roles that the object plays. The collections of operations snipped from the Use Case scenario are called roles. We want to capture them in closed form (source code) at compile time, but ensure that the object can support them when the corresponding Use Case comes around at run time.

... an object of a class supports not only the member functions of its class, but also can execute the member functions of the role it is playing at any given time as though they were its own. That is, we want to inject the roles' logic into the objects so that they are as much part of the object as the methods that the object receives from its class at instantiation time.

Ah there it goes. Method injection it is. But why should an object have a role-specific method at all? Probably just because of data-hiding?

The software exhibits the open-closed principle Whereas the open-closed principle based on inheritance alone led to poor information hiding, the DCI style maintains the integrity of both the domain classes and the roles. Classes are closed to modification but are opened to extension through injection of roles.

Uh, that's why? Ok.

So instead of doing DCI, my suggestion is to open the data, screw the language integrated enforcement of the open-closed principle (and solve that by convention and tests), and implement simple play functions that receive data structures as arguments and name the parameters according to their rules. Probably we need some additional functions that are rule specific (the ones DCI needs to inject), and that's it.

My conclusion is that DCI may be a solution for a missing bit in the OO world but has no use when you are flexible enough to let go of data-hiding.