We started with a look at what Evans considers the most essential parts of DDD - creative collaboration between the software experts and the domain experts was identified as being important if we are to end up with a good model. If we can make the process of defining the model fun then all the better but we need to utilise domain experts properly and not bore them. 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’re modeling we need to come up with at least three models - don’t stop at the first model, it’s probably not going to be the best one. If we stop after one model then we’re leaving opportunities on the table - white boarding different models is a very cheap activity so we should make sure we take advantage of that and do it more frequently. 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.

He touched on a couple of others including the need to constantly reshape the domain model as we learn more about it and that we can get the biggest gain from DDD by keeping the focus on our core domain before we got onto explicit context boundaries - I’ve always found this to be the most interesting part of the book and Evans said he wished he’d made it one of the earlier chapters. 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.

We moved onto the building blocks of DDD - services, entities, value, objects, factories, repositories - which Evans considers to be over emphasised. They are important but not essential. Evans did also point out that value objects tend to get neglected. This was also mentioned in several of the other presentations.

Despite this Evans added a new building block - domain events. He described this as 'something happened that the domain experts care about'. They provide a way of representing the state of an entity and lead to clearer, more expressive model. This sounded very similar to an approach Nick has described to me whereby we would have a new object that represented a specific state of an object. 'Every change to an object is a new object' was the take away quote from this part of the talk for me - I think an explicit approach to modeling is far superior to an implicit one. 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.

Evans made an interesting point when talking about strategic design - just because you have been working in a domain for a long period of time does not make you a domain expert. There is a subtle difference between someone working as a software expert in a domain and the actual domain expert - when looking at problems the software expert is responsible for looking at how software can help, the domain expert is responsible for removing that problem!

Evans came up with a context mapping step-by-step which he said could be followed to help us work out where the different bounded contexts in our system are and how they interacted:

He also added a couple more patterns in this area - big ball of mud and partners. For big ball of mud he said we should identify these in our context maps and then not worry too much about applying design techniques when in this context - just take a pragmatic approach and 'reach in and change it' 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.

Some final take away quotes included 'not all of a large system will be well designed' and 'precision designs are fragile' - where we have the latter in our code we need to protect them with an anti corruption layer and with the former we should pick a specific area (that matters) to design well and accept that other bits might not be as good as this bit. </ul> 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.