QCon London 2009: What I've learned about DDD since the book - Eric Evans
I went to the QCon conference in London on Thursday, spending the majority of the day on Eric Evans’ Domain Driven Design track.
The opening presentation was by Eric Evans, himself, and was titled ‘What I’ve learned about DDD since the book’.
We’re currently reading Domain Driven Design in our technical book club in the ThoughtWorks Sydney office so I was intrigued to hear about Eric’s experiences with DDD and how those compared with ours.
The slides from the presentation are here.
Taking a domain expert through some screens and talking about the validation needed on different fields is a bad way to use them - they want to do valuable work and if this is their experience of what it’s like working with the software experts then we’ll never see them again.
When we talk of three models Evans’ pointed out that these should be different to each other and that this would involved coming up with some radically different ideas. Creating an environment where we can celebrate ‘bad’ ideas is necessary to encourage people to step into the riskier territory. If we’re only coming up with good ideas we’re not being creative. This was a definite take away for me - I’m certainly guilty of only considering the first model I discover so this is something to improve on.
I spoke with him afterwards about whether or not the UI was considered to be a separate bounded context. He said to consider a bounded context as an observation [of the system] and that if the model of the UI was significantly different to the underlying model then it would be reasonable to consider it as another bounded context.
The example given was a baseball game where a domain event might be someone swinging at the ball - when this happens statisticians will need to be informed so that they can update their statistics i.e. we often want to record to events that happen in our domain. He described the use of an event stream which we could put events onto and they could be subscribed to by whoever cares e.g. the reporting service.
I’ve never drawn a context map before but it sounds like a potentially valuable exercise - might try and do one for my current project!
Partners was described as being similar to a three-legged race - both teams need to cooperate on their modeling efforts because they have a mutual dependency, neither can deliver without the other.
Gojko Adzic has a write up of this talk as well - a very informative talk and it’s definitely cool to hear the guy who coined the approach talking about it.