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.

A select group turned up for the third installment of the Oxtremists at “Far from the Madding Crowd“. Along with me of course, Miquel, Steven and David came to talk about “Domain Driven Design” by Eric Evans.

We started off with some general discussions about the book, although none of us had actually got past the halfway mark. Miquel mentioned that he found the book a little repetitive, so that the author would mention something several times as well as going into more depth in later chapters.

Miquel said he was unsure about quite how the model is supposed to be expressed. In the book, there are lots of UML diagrams. Is Eric Evans suggesting that we need to keep lots of UML diagrams in synch with the code? Or is this stuff just supposed to be documented in English, or what? Miquel said that he had tried to keep diagrams up-to-date in the past and that it was very tough. Perhaps since you are only worried about keeping a model of the domain and nothing else (no application, user interface or infrastructure code) then this task becomes less onerous? David suggested that in most Agile methodologies you wouldn’t try to keep UML diagrams up-to-date and that you’d draw them when needed and then throw them away.

I said that it seemed to me that if you were going to follow the recommendations in this book, everyone involved would have to read it. Because otherwise your precious domain model and layered architecture could fall apart quite quickly.

I pointed out the example on p19, where there is discussion of booking cargo onto ship voyages. Apparently, much as in airlines, there is a tendency to overbook so that the ship will still leave port fully loaded if some containers fail to show up. In this example, the rule “You may overbook by 10%” was moved from a method in an application class into a domain class (using the Strategy pattern). The suggestion was that this was not done because this rule was likely to change, but because the rule now had a name and could be discussed as part of the domain. I found this an interesting way of thinking about the modelling whereby you refactor to make the model more expressive rather than for functional reasons.

We talked about the concept of the ubiquitous language which is supposed to be used by everyone involved in project, the developers, customers and anyone else. Miquel pointed out the irony that the author uses UML aggregates in his diagrams but has his own kind of aggregates. So his own ubiquitous language is inconsistent! I said that it was interesting that Eric Evans talks about refactoring the language as you would refactor code and then feed this refactoring through to the code (p31). David in particular was a little unsure about what “refactoring” that language actually meant. Telling your customers to use different words? I suggested that it might just mean changing the way the different words related to one another once you’d got a better understanding of the domain. David said that customers can actually use confusing terms themselves and told us about a customer who used the terms “instant” and “instance” the wrong way around. So perhaps sometimes you do have change the customer’s language? He said that he thought having a Project Glossary was a good idea, although Steven said that no-one ever reads them.

There was some discussion of the concept of “Aggregates” (the ones described in this book, not the UML kind). I suggested that they were a good idea in principal but I thought they might be hard to define in practice. Miquel was more optimistic. The idea is that you group objects together and can only access objects inside an aggregate through one “root” object. Miquel said that often the root would only give references to copies of the objects inside the aggregate so that it could keep control of them. He also said that doing modelling as suggested in this book was a good way to get back to true object oriented principles with rich objects having their own responsibilities. We then talked about how there is a need to use Factories and Repositories to manage the life-cycle of your objects as they get persisted to and from a database. David thought that perhaps in the not-too-distant future we would not have to worry about doing the persistence ourselves. He pointed out that in the old days programmers were worried about memory allocation and grabbing individual 4K chunks and so on. Virtual memory management had removed that, so we work (almost) as if memory was unlimited. Perhaps an object oriented version of that could be created so that unused objects would get automatically paged to disk.

We briefly touched on Packages/Modules and I mentioned how the author says that no-one ever refactors them. The individual classes change internally, but rarely move. This can lead to a poor overall structure. At this point Steven said that he had indeed done some package refactoring recently, so perhaps reading this book has paid off already?

We ended up talking about the Layered Architecture as described in this book and how that relates to the classic Model, View, Controller pattern (MVC). Miquel was concerned about where the Model in MVC lives in this. He seemed to be suggesting that the controller which lives in the application layer would ask the domain layer for some data and pass this to the view (in the UI layer). This means that the model is not really part of the domain layer, but separate from it. I guess that means it is part of the application layer? Hopefully he will correct me if I didn’t follow his argument completely!

Finally there was a brief discussion about the book for next time. I will not be around, so I’m quite happy to read the second half of “Domain Driven Design”. Steven wanted to finish the book too, but perhaps others will want to look at something new instead?