dci ddd-be april 2015
TRANSCRIPT
Herman PeerenDDD-BE
April 2015
DCIData - Context - Interaction
Trygve Reenskaug James Coplien (Cope)
playing roles
not all behaviour at the same time
This picture and on coming pages example from Victor Savkin: http://www.sitepoint.com/dci-the-evolution-of-the-object-oriented-paradigm/
what the system is< >
what the system does
•anemic model, “data”•adding behaviour in a “context”•behaviour grouped in roles•context = use case, scenarios
•model matches mental model•readability of object oriented code•object oriented < > class oriented
• http://fulloo.info/Documents/• http://en.wikipedia.org/wiki/Data,_context_and_interaction• https://groups.google.com/forum/#!forum/object-composition
•separating behaviour from data
Behaviour is composable•like in Functional Programming
At the moment we can see a tendency to decouple behaviour from objects!
Example: evolution of “services”Eric Evans (2004):•an operation offered as an interface•without encapsulating state•should be use judiciously•not to strip entities and value objects of all their behaviour
Debasish Ghosh (2015):•more macro level abstraction than entity or value object•involves multiple entities and value objects•usually models a use case of the business
“Data” don’t exist
•in Functional Programming•and Event Sourcing
Data, state is
•a left fold•a snapshot•a result of a stream of events
•then what about
DATA? - Context - Interaction
•if we implement that with Event Sourcing•we have events as a result of interacting roles•a “context” instead of an “aggregate”•roles played by a reconstituted stream of events
•can we learn from DCI for better
Domain Driven Design?
•behaviour related to use case / scenarios•adding behaviour at runtime (roles)•better names (context, role)•algorithm more a whole, readability•a model is not a tree...
