1. DCI
Data Context Interaction:
Re-thinking the foundation of object orientation and of
programming

2. DCI: Introduction
• Invented by Trygve Reenskaug (MVC)
• Refined by James O. Coplien
• The paradigm separates the domain model (data) from use cases
(context) and roles that objects play (interaction).
• Complementary to model–view–controller (MVC).
Objectives:
• Improve the of object-oriented code readability
• System behavior gains first-class status;
• To cleanly separate code for rapidly changing system behavior (what the
system does) from code for slowly changing domain knowledge (what
the system is)
• Help software developers reason about system-level state and behavior
instead of only object state and behavior;
• Support an object style of thinking that is close to peoples' mental
models, rather than the class style of thinking that overshadowed object
thinking early in the history of object-oriented programming languages.

3. From procedural to object
orientation
• 1960 – 1970 Procedure Orientation: Succes
1. Data-centric architecture for separation of state and behavior
2. Application design with functional decomposition
3. Textual code flow reflects process flow
4. Peer review of code chunks to get it right the first time
5. Testing as a “no blunder” confirmation
• 1971 – 1995 Class Orientation: Collapse
1. Class-centric architecture with ecapsulated state and
behavior
2. System design with functional fragmentation
3. Fragmented code NOT show process flow
4. No Chunks: no peer review
5. Code correctness can only be explored by tests

4. Decomposition vs
Fragmentation
Big Algorithm split
in several little chunks
Where is the algo?

5. All is about objects
• Class oriented programming
• OO fails to capture behavior
• No obvious “place” for interaction to live
• Failure to capture the user mental model
• Algorithms: from procedural approach to distributed
algorithms (coupling and cohesion)

6. Class oriented programming
• Nouns are objects and verbs are methods
• Objects are supposed to be stable
• Behavior changes frequently
• Artificial solution: using inheritance to express "programming
by difference" or "programming by extension”
• Open-closed principle: the vernacular of the design
• Liskov Substitution Principle
• Favor composition over inheritance (16)
• Domain classes should be dumb!? An anemic domain model
approach?

7. Transaction Scripts and Service
Layer
• Poor domain model
• Transaction Scripts • All the usecase and domain logic into
• No Domain Model the Transaction Script
• Duplicated code
• Rich domain model
• Thin/No Service Layer • Service layer as a facade
• Domain Model • Uses case centric behavior fails to fit
• Rich domain model
• Thick Service Layer • Thick Service layer
• Unable to reuse code in other
• Domain Model applications
• Cross Services code duplication

8. Users and programmers
mental models

9. System Operations executed by
Contexts

10. Roles and DCI
• Combining Structure and
Algorithm in an Class
• Combining Structure and
Algorithm in an Object

11. DCI and User Mental Model

12. End User and Programmer
reconciliation

13. MVC
• Information is a key
element of the end
user mental model
• Not a set of Observers
• MVC-U is all about
making connections
between computer
data and stuff in the
end user's head
• Capture well what the
system is but NOT
what the system does.

14. DCI and MVC
• Mapping roles to Objects
• Controller works with
Contexts
• One context per Use Case
DCI components:
• The data, that live in the
domain objects that are
rooted in domain classes;
• The context that brings live
objects into their positions
in a scenario, on demand;
• The interactions, that
describe end-user
algorithms in terms of the
roles, both of which can be
found in end users' heads.

15. From procedural to object
orientation
• 1960 – 1970 Procedure Orientation: Succes • 1971 – 1995 Class Orientation: Collapse
1. Data-centric architecture for separation of state 1. Class-centric architecture with ecapsulated state
and behavior and behavior
2. Application design with functional 2. System design with functional fragmentation
decomposition 3. Fragmented code NOT show process flow
3. Textual code flow reflects process flow 4. No Chunks: no peer review
4. Peer review of code chunks to get it right the 5. Code correctness can only be explored by tests
first time
5. Testing as a “no blunder” confirmation
• 2000 True Object Orientation: A new Beginnig
1. DCI architecture for separation of system stae and behavior
2. Functional separation in Context with Roles
3. Methodful roles show process flow
4. Peer review of code chunks to get it right the first time
5. Testing as a “no blunder” confirmation

16. Templates Traits Mixins
• C++
. . . . template <class ConcreteAccountType> class
TransferMoneySourceAccount {
public: void transferTo(Currency amount) {
beginTransaction();
if (self()->availableBalance() < amount) { . . . . }
. . . . class SavingsAccount:
public Account,
public TransferMoneySourceAccount<SavingsAccount> {
public: void decreaseBalance(Currency amount) { . . . . }
}
....

17. Templates Traits Mixins
• Scala Trait
trait TransferMoneySourceAccount extends SourceAccount {
this: Account =>
// This code is reviewable and testable!
def transferTo(amount: Currency) {
beginTransaction()
if (availableBalance < amount) {
....
}
}
....
val source = new SavingsAccount with TransferMoneySourceAccount
val destination = new CheckingAccount with TransferMoneyDestinationAccount
....