Introduction

Object-oriented programming was supposed to unify the perspectives of the programmer and the end user in computer code: a boon both to usability and program comprehension. While objects capture structure well, they fail to capture system behavior.

DCI (Data, Context and Interaction) is a programming paradigm through which the end user mental model is more fully reflected in readable code. The vision of DCI is to become a unifying foundation for programming in both introductory and advanced programming education, and to bridge the gap between programmer and everyday user through concepts that everyone can understand.

To quote from the article Working with objects—in computer and mind, the primary goals of DCI are as follows:

Mental models - To reflect the way different users conceptualize the objects of their world so that a program feels like an extension of its user's mind.
Reasoning - To help software developers reason about system state and behavior in addition to the state and behavior of isolated objects.
Readability - To improve the readability of object-oriented code by giving system behavior first-class status.
Reuse - To be able to reuse old solutions for new purposes.
Revision - To cleanly separate code for rapidly changing system behavior (what the system does) from code for slowly changing domain knowledge (what the system is), instead of combining both in one class hierarchy.

Alan Kay introduced the notion of object orientation in the early seventies. He regarded an object as a virtual computer and an object system as many computers hooked together by a very fast network. Fundamentally, a computer offers three simple services: it can store data, process data, and communicate data.

DCI achieves these goals by considering three fundamental aspects:

Data - The “storing” function of a system is realized by the Data model, which is comprised of objects representing the structure and relationships of a domain.
Context - The Data model gives rise to objects that will collaborate to implement use case scenarios and other system operations. Object interaction takes place within a Context where the objects are identified by the Roles they play. Objects are temporarily extended with Role Methods while they are playing a Role. The Context orchestrates which objects play which Roles.
Interaction - At runtime, the environment will trigger the Context to start the Interactions between the role-playing objects. These Role Players will send messages to each other in order to fulfill the system operation. Runtime parameters might vary the topology of interactions within a Context, e.g. if a use case has various scenarios. The interactions form a structure that closely reflects our human mental model of the behavior of our domain.

Communication - The missing part

In traditional class-based programming, “storing” and “processing” code is placed together in the same class, and the code for “communicating” (communication between objects) is often scattered across many different classes. DCI is more truly “object-oriented”: objects still contain both data and behavior at runtime, but DCI avoids the often incorrect assumption that system behavior shares the same structure as the data model. This is accomplished by clearly delineating the storing, processing, and communicating capabilities in the code, allowing the programmer to orchestrate how these elements will combine to form objects at runtime and their interactions with each other.

Encoding behavior as a first class citizen in the Context firmly consolidates our ability to reason about what the code will do at runtime without having to study a plethora of classes or prototypes of role-playing objects. This has an array of advantages.

Advantages

DCI allows:

Programmers and other stakeholders to more easily synchronize their mental model of the domain
New programmers to more easily understand what a program is supposed to accomplish
Current programmers on a DCI project to more easily maintain and debug the code base
Managers and end users to more easily review domain behavior in Contexts together with programmers

Key aspects

The key aspects of the DCI architecture are:

Separating what the system is (data) from what it does (function). Data and function have different rates of change so they should be separated, not as it currently is, put in classes together.
Create a direct mapping from the user's mental model to code. The computer should think as the user, not the other way around.
Make system behavior a first class entity.
Great code readability with no surprises at runtime.

DCI and MVC, connected

In many ways, DCI builds on the same concepts that underly MVC (both were invented by Trygve Reenskaug). In MVC, the Model is intended to make the computer feel like an extension of the user's mind, made accessible by supporting Views and Controllers. In other words, MVC transforms the Model data into a physical form that can readily be assimilated by the user’s brain. DCI is about creating a program that faithfully represents the human mental model. The two meet when MVC is used to bridge the gap between the human mind and the model implied by the DCI-based computer system:

Illustration from Lean Architecture (p. 238)

History and common sense argue that users can reap the full value of software only when they understand how the system works, the ideal being that stakeholders can understand critical parts of the program and that some can even write code themselves. DCI makes this goal practical and achievable today. Store, process, and communicate: so simple that everybody can understand it, so universal that it can form the nucleus of computing in business and school.