Data, context, and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects.
Its goals are: The paradigm separates the domain model (data) from use cases (context) and Roles that objects play (interaction).
The data design is usually coded up as conventional classes that represent the basic domain structure of the system.
These classes are barely smart data,[1][2] and they explicitly lack the functionality that is peculiar to support of any particular use case.
These data implement an information structure that comes from the mental model of end users, domain experts, programmers, and other people in the system.
The Role-to-object bindings that take place in a context can be contrasted with the polymorphism of vernacular object-oriented programming.
[5] The overall business functionality is the sum of complex, dynamic networks of methods decentralized in multiple contexts and their Roles.
[5] At use case enactment time, each and every one of these identifiers becomes bound to an object playing the corresponding Role for this context.
A Role is a stateless programming construct that corresponds to the end user's mental model of some entity in the system.
Whereas vernacular object-oriented programming speaks of objects or classes as a multiplicity of responsibilities, DCI ascribes them to Roles.
The Qi4j programming environment offers a way to express Role method injection into Java objects.
[5] During the enactment of a use case (like Serve the Wine) the Role Waiter unambiguously identifies a single object at any given time.
Even if their responsibilities are identical, they would still be described as Waiter-1 and Waiter-2, or as individual (named) elements of a Waiter vector, if someone intended to write software for them.
The code is dominated by the use case structure, which cuts across the objects, and which also is part of the Interaction facet of DCI.
The type of object is chosen according to the kind of use case that will ensue, based on information about the trigger or the system state or both.
For example, a cash machine might have separate Context classes for money transfer, withdrawal, deposit, balance inquiry, and so forth.
Once the environment instantiates the Context object, it invokes its trigger method to start the use case enactment.
Code for the basic domain logic is implemented separately, following conventional object-oriented practice and most commonly using classes.
Haxe uses its compile-time macro feature to transform the DCI semantics to target language code.
[1][3][9] DCI arose largely as an outgrowth of Trygve Reenskaug's work on role-based modeling.
Further, the fact that object-oriented programming languages offered only classes to express program logic left the programmer at the mercy of the structural layout of the data to delineate behavior, which is unnatural compared with a delineating behavior on Role boundaries.
[citation needed] Trygve felt it was important to create program structures about which one can reason, and started socializing these ideas as early as 2000.
Steen Lehmann, Rickard Öberg and Niclas Hedhman accelerated adaptating these ideas to Ruby and Java over the next year or so with the Qi4j framework.
Marvin was mainly meant as a proof of concept to showcase the idea of "injectionless DCI".
This is aligned with the theories behind DCI and it should encourage further and systematic investigations concerning the possibilities of this paradigm.
"[15] According to researchers Bluemke and Stepień at Institute of Computer Science, Warsaw University of Technology, "DCI based systems are very flexible much more than the traditional ones, this is due to the fact that static (Data) and dynamic (Context, Interaction) parts of the system are separated and separation of concerns is very powerful strategy to master the complexity.