In this talk he makes some similar points to those that he made in his 'What I’ve learned about DDD since the book' presentation that I had the chance to see at QCon in London last year. One of these is that there is no such thing as a "right model" - there are only models and some will help us describe our system better than others.

Evans suggests that we need to spend most of our time modeling in the core domain since this is the code that gives us a competitive advantage and allows us to differentiate ourselves from competitors. I often wonder where the best places to focus efforts on code bases is and I’ve typically been of the opinion that the pain points are the best place to work on since we can see an immediate reward from doing this. As I’ve mentioned before I quite like Fabio’s technical debt quadrant as a mechanism for measuring where we should focus our efforts with this approach. It still seems different to what Evans suggests although I’m inclined to believe that the areas of most pain could well be the areas we need to be subtle to change and there could therefore be some correlation between those areas and the core domain. I’ve not seen a distinction between the core domain and other parts of the domain model on any projects I’ve worked on so it’d be interesting to hear other opinions on this.

A related point to this which I haven’t completely grasped is that there are some areas of the code which we shouldn’t bother trying to improve and instead should just work around and not worry too much about creating intricate models. I like this advice in a way although it seems a little dangerous to me and perhaps seems to conflict with Uncle Bob’s idea of following the boy scout rule and improving the code slightly every time we touch it. As I understand it, Evans advice would be to only follow this advice when we’re working in the core domain.

Evans points out that we should try to avoid the universal domain model, something which Dan North also points out in his article on SOA. As I see it we can either decide to explicitly mark out multiple different models in our code explicitly otherwise we’ll just end up with one mediocre model being bent to fit the needs of every part of the system. I guess it seems intuitive to try and reduce the amount of code required in a system by just doing the modeling once but different teams in different contexts have different meanings and uses for the model that it doesn’t make sense as an approach.

My favourite quote from the presentation is the following: