The DCI Architecture

To its end user, software is not a product, but a service. Procedural programming made it possible to reason about these services and their logic in which most problems could be found in low-cost but dutiful desk checks. The main building block was the procedure, which could be assembled to collect large numbers of activation record instances into a few archetypical structures. In 1967, the ability to do this was taken away by object-oriented programming, which encouraged a style of programming where this user-focused structure was subordinated to the user's cognitive model of the static world: of its objects. The algorithmic view was further muddled by inclusion polymorphism. The Smalltalk anthropomorphic view and ever small method sizes made it necessary to understand dozens of atomic algorithms to understand even the simplest functionality. Progress in methodologies reduced this static view to an even more over-simplified and more static view in classes, the almost final step in removing our ability to reason about the end user system model. The final step was Agile methods, which focus on the customer -- the middleman -- instead of the end user, enabling a product focus instead of a service focus. This is even celebrated as a good thing.

Piecemeal, technology has slowly staggered roughly in the direction of the more primordial object view, and AOP has struggled to restore some of the algorithmic view. Roles and role-based modeling have brought back a bit more dynamic view of the system; we find their incarnation in Java and C# interfaces. There is renewed interest in dynamic programming languages and in the kind of flexibility one finds in traits. Trygve Reenskaug has combined these techniques and brought us full circle in the DCI paradigm. The "D" is for data modeling: what we know as traditional objects, though bereft of knowledge about scenarios. It captures the static structure of objects and their references on the heap. The "C" is for context: the mapping of roles onto objects on a per-use-case basis, implemented as a dictionary. The "I" is for interaction: an algorithm of a stateless role, written in terms only of other roles, that defines in readable terms what the system does, and how it does it. Object dynamics can be captured in interaction roles and melded with classes who use the roles as traits; interaction dynamics appear in a context object generated anew for every use case; and structural dynamics appear as references between elements of object data.