What is the best description of Data, Context and Interaction (DCI) to pitch it to an organization?
It\'s created by Trygve Reenskaug, the creator of the MVC-pattern.
A good question and an often occurring question. The short answer is that it's a paradigm on it's own based upon the founding ideas of OO by Kay, Dahl and others. It was created by Trygve Reenskaug as you note with several goals in mind. One of them being tha aim of making IO operations first class citizens of the program. (not IO as in disk operations but all communication between two different objects). Another important goal of DCI is to split what the system does (functionality/behavior) from what the system is (data)
The impression I got is that it's not a successor to MVC so much as a complement, for example figure 5 in the artima article on DCI has both. I think it's supposed to help make the distinction between model and controller more sane, or maybe between different part of the controller or different parts of the model.
The basic idea seems to be to split logic for particular actions our of your data classes and move it to traits/mixins/whatever, one per (user) action. You'll have many small pieces of code, instead of a few large pieces. Also, it sounds like adding new mixins is supposed to be "better" than adding functionality to your base classes. The code for individual actions will probably (I think?) be more spread out, but code for different actions should be more clearly and obviously separated.
I think improved system comprehension is a huge win for any organization, but you could also make the case that DCI is an improvement on MVC due to the following additional factors:
Trygve makes a presentation of DCI in https://vimeo.com/8235394
DCI has been created to solve a problem in object orientation: it's too difficult to review OO code.
The code for one use-case in OO is typicall spread out between lots of classes. To understand how the code works, you must also know the relationships between objects in runtime. These relationships aren't set in code, they depend on the situation.
What DCI proposes is that code for a given use-case is separated out from the classes and put into a different artifact called context. Objects of different classes can enter into a relationship in this context and take part in interaction where they have different roles.
The whole point of DCI is to make OO code more readable!
That's how I would pitch it.
It totally looks to me as the Policy based design by Andrei Alexandrescu in Modern C++ design, however that work is more low level, DCI looks like an architecture with parts of methodology (use cases drive the design).