There were just four of us here to look once again at Domain Driven Design (DDD): Myself, Tom, John and Ursula. Tom began by saying that he hadn’t re-read Eric Evans’ book but that he had actually been trying to apply it since we last looked at this topic. He admitted that it was quite difficult, but that going back he’d found the key sentences that he’d missed when reading it the first time. He found that initially it is easy to get swept up in a wave of object oriented enthusiasm. But when you go back and look, Eric Evans is saying that you have to make compromises in some places. Ursula suggested that there is always a danger when learning a new pattern that you overuse it.
My initial thought was that the difficulties lie in the associations between objects. The ‘pure’ OO approach would yield a huge web of objects that just wouldn’t be practical. Tom agreed and said that going back and looking at the discussion of when to use association traversal and when to use a search was the key thing in this area.
John asked how hard it is to actually use the techniques described by Eric Evans. Tom admitted that it was hard and that you are constantly assessing how to proceed.
Ursula wanted to know about how you cope with the situation where one team builds a system using DDD and then another team takes ownership. My take on this was that it is very difficult indeed for the model to survive this transition. As Eric Evans describes on p3 of his book, the model is really a mental model. Any diagrams, documents or discussions of it are really just a view into that model, not the model itself. Tom said that you really need a permanent person to look after the model.
Ursula then asked about whether the modelling is done for the applications you are building today or if it is supposed to be a foundation for future development. I mentioned that Eric Evans talks about updating the model as new insights are gained and that he seems to suggest that it is possible that the model itself suggests future possibilities (Chapter 8). Tom was a little skeptical on this point.
Tom said he has found that the domain experts he has worked with have never seemed to be as good as those described in the book. John said that sometimes they find it hard to visualise what could be done, so there is always a gap between the developers and the domain experts. Often you need to produce a prototype just to get discussions going, but the Ubiquitous Language also helps to close this gap.
We then looked in particular at the part of the book in Chapter 7 where there is a discussion about how to design the associations, aggregations and so on, looking at an example. Tom said that he had an “aha” moment on p171 where the Handling Event object was not part of the Cargo aggregate, when he would naturally have put it inside. I mentioned that we’ve seen the problems of developing without the use of Aggregates in our codebase. So I’m definitely a fan of moving to the use of this pattern.
I also had a question about something on p171 – I wanted to know how the fact that the Delivery Specification object is a Value Object would affect the implementation of it. We had another read and it seems likely that the object would be immutable, shareable and cacheable (are those real words?). I found the idea of mutable value objects a difficult one. Looking at the discussion of this on p100 it seems that generally you shouldn’t do this, but that it is sometimes needed for performance reasons.
Ursula talked about the difference between an Analysis Model (which just models the domain) and a Design Model (which contains implementation details) and how those concepts fit into DDD. My take on this was that in DDD you do both types of modelling at the same time and that things like aggregates and the way associations are modelled are purely implementation specific, so are not really an artifact of analysis.