The DCI Architecture: Lean and Agile at the Code Level
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
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.
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.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Abstraction, abstraction...
by
Paul Beckford
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.
Paul.
Templates Vs Inheritance
by
Patrick Dooley
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
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?
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think