Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations The DCI Architecture: Lean and Agile at the Code Level

The DCI Architecture: Lean and Agile at the Code Level



James Coplien explains the DCI (Data, Context, Interaction) paradigm used to better represent the user’s mental model in code through system state and behavior. Coplien makes an attempt to reintroduce architecture to Lean and Agile projects due to its value in sustaining high velocity and change resiliency.


Jim Coplien is a Senior Agile Coach, software developer, and Systems Architect working at Gertrud & Cope. He is a well-known industry speaker, author, and innovator. His past work has included architecture, design, and implementation in the EDA industry, as well as leading positions in academics, Bell Labs Research, in telecom R&D, and in international consultancy.

About the conference

QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

Recorded at:

Jun 30, 2010

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Abstraction, abstraction...

    by Paul Beckford,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great presentation. I read an article about DCI before, but didn't get it. James does a great job here of getting his point across. The idea of use-cases as their own abstraction is a powerful one. Also, I've always been confused between the difference between an objects role and its (domain) class. DCI provides an answer.

    I haven't followed through the code example bit yet (brain overload), but I can't help thinking that perhaps classes should be avoided all together, and the required role needed to support the context (use-case) should be built up dynamically by mixing in the appropriate role trait. The Self language came to mind.

    One thing it drove home, is just how difficult it is to come up with software abstractions that map well to the abstractions in our brain. I guess its the powerful R-Mode pattern matching feature of the brian that allows us to perceive patterns and abstractions that are very difficult to replicate in software. Is the added cost and complexity of DCI worth the benefit? I don't know.

    One nit-pick. I didn't buy the link with Lean (or even Agile for that matter). Not sure if it helps, other then tying this idea to some fashionable buzz words. For example DCI doesn't sound like the simplest thing that could possibly work... and could even be considered YAGNI.

    I think it is going to take me a while to digest this one. Thanks for getting this content out there.


  • Templates Vs Inheritance

    by Patrick Dooley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I am very happy to have had the opportunity to delve deeper into DCI. I finally resolved myself to work through the OOram book and I think that the distillation of OOram to DCI is commendable. I heartily agree with Mr. Coplien that the model in the mind must be captured in the architecture. We definitely need to move away from our grandfathers’ OOP and fast.

    I am not convinced that creating polymorphism through templates and calling it Role/Context is that much different from using inheritance to create objects with varying strategies. Certainly, one can create the same "Form" by interchanging the use of inheritance with the use of templates. What one chooses to use is personal preference I suppose. I myself prefer to leave them in the realm of containers and algorithms. What I find alarming is the claim that I will attain OOP nirvana by removing inheritance from my arsenal of software tools. Please don't take away my inheritance - I beg you.

    Is the key objective of DCI to create software that can be more easily understood and mentally verified? I do not disagree that these constructs provide the ability to present the logic - the user stories - in a meaningful way. I am just not convinced that this paradigm provides a level of clarity greater than that which can be achieved through the use of aggregation and inheritance.

    Does Mr. Coplien propose this paradigm as a stepping stone to OOP? A way of helping the masses get on the band wagon? I see value in this approach as a teaching aid, one that could help people to train themselves to think in terms of objects.

    Certainly DCI is a helpful construct for a certain class of problems. But I can think of other classes of problems where the usefulness of this construct is not so apparent. I am currently developing a tool to simplify RIA development and I am hard pressed to think of a DIV element as a role played by an HTML element. I have spent the majority of my career developing tools to simplify development and to maximize re-use. IMHO this is a big part of OO development where DCI does not seem to apply.

    I am very grateful to Mr. Coplien for using his prodigious intellect to help further illuminate the murky waters of OOP. Unfortunately, I am just not convinced that the distillation process is complete.

  • Outstanding presentation! But I'm struggling with the examples...

    by Piotr Włodarek,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    James Coplien is amazing thinker and I truly recommend this talk to anyone interested in OOP!

    However, is it just me dumb or the example at 0:50 is simply messy?

    Why not TransferMoneySource and TransferMoneyDestination (for symmetry's sake)?

    Why increaseBalance and not increase_balance?

    What is self.withdraw? The Account domain model was not supposed to have methods like this.

    And most importantly why the TransferMoneySource role mixes business logic and GUI? Shouldn't we simply return a successful status to keep roles (and use cases) frontend-agnostic?

  • Re: Templates Vs Inheritance

    by Oleh Novosad,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Inheritance is bad. Composition is better. Roles are the best.

  • A recipe for functional programming into your business domain

    by sontu cosmin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think DCI is a great approach that fits into any architecture. You can implement your business domain with it and it's your launching pad for applying functional programming correctly into your domain.

  • DCI in Kotlin

    by Tom William,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Could please do a Kotlin example of DCI?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p