This articles was originally published here.
When we went from procedural programming to object-oriented programming, by realizing that we could remove the “object pointer” as the first argument to a procedure, and instead went to a model where methods are invoked on objects with identity, it fundamentally transformed our ability to structure and reason about software. Now, with the introduction of the DCI paradigm, I think that a similar change is possible, by realizing that DCI contexts are to stateless services what objects were to procedures.
To understand this you have to start with understanding where DCI fits into a typical enterprise architecture, because by doing so you can compare with other ways of doing the same thing. The basic idea of DCI is to select a number of objects into a Context, and then perform Interactions on it. The Interactions represent the developers mental model of the software, and as such are a good way to implement usecases.
So if you don’t use DCI, how would you do the same thing today? The typical approach is to use stateless services, where each method takes a number of parameters, some of which are object identifiers, and some of which are “real” parameters, like strings and ints, that you use to handle the variation of what the method can do. In other words, DCI goes mainly into the application layer of a system.
At this point, let’s make a comparison. As mentioned, with the transition from procedural to OO we went from:
And with DCI we are now going from:
Can you see the resemblance in approach? By explicitly introducing an identity, but this time of a set of objects rather than just a single object, we can simplify our interactions in the same way that object methods simplified procedures. We no longer have to do the lookups of the objects, validate that they are ok, validate their relationships, and so on. Instead all of that is done in the construction of the Context (much like how a constructor initializes an object), so that the Interactions can focus on what to do with it. My previous post on DCI shows some example code for this, and I can see that in my own codebase the structure and implementation has been radically simplified because of it. It was made even more clear since we started with a non-DCI solution and then refactored it once the realization hit us. Tears were shed I can tell you once we saw how much simpler everything became.
There is probably more to be said about this, but the basic idea is simple enough and powerful enough to be just what I presented above: I think that the contexts in DCI will replace stateless services, just as objects replaced procedures in its time. And it is going to be simplifying and clarifying our software radically. For those of you who have had the question “What should I use DCI for?”, this is it.