Mark Needham

Thoughts on Software Development

QCon London 2009: Rebuilding with DDD – Phil Wills

with 5 comments

Talk #3 on the Domain Driven Design track at QCon was by Phil Wills about how the Guardian rebuilt their website using Domain Driven Design.

I’d heard a little bit about this beforehand from colleagues who had the chance to work on that project but it seemed like a good opportunity to hear a practical example and the lessons learned along the way.

There are no slides available for this one on the QCon website at the moment.

What did I learn?

  • Phil started by explaining the reasons that they decided to rebuild their website – tedious manual work was required to keep the site up to date, they were struggling to hire new developers due to their choice of technology stack and it was difficult to implement new features.
  • They were able to get domain experts very involved with the team to help define the domain model and trusted the domain expert to know best. I think the difficulty of making this happen is underestimated – none of the projects that I’ve worked on have had the domain expert access that Phil described his team as having. The benefit of having this was that they had times when the business pointed out when the model was getting over complicated. The takeaway comment for me was that we should ‘strive to a point where the business can see and comprehend what you’re trying to achieve with your software
  • Entities are your stars but we need to also think about value objects. Entities have the maintenance overhead of having life cycle that we need to take care of so it makes sense to avoid this wherever possible. Phil showed an example of an entity class with around 50 fields in which could have been severely simplified by introducing value objects. Every time I heard value objects being mentioned it reminded me of micro/tiny types which are not exactly the same but seem to be fairly similar in their intent of improving expressiveness and making the code easier to work with. The importance of value objects was also mentioned in Eric Evans talk.
  • The database is not the model – Phil repeated this multiple times just in case we didn’t get the picture, and it was something Dan mentioned in his talk as well where he referenced Rails use of Active Record as being a particular culprit. Phil mentioned that this had been a difficult idea to grasp for some of the team who didn’t give full status to data that didn’t have a corresponding place in the database.
  • The Guardian’s core domain is articles – they look to use 3rd party solutions for parts of the website which aren’t part of the core domain. For example football league tables are pulled from a 3rd party content provided who sends the data in a format which can be easily displayed on the website. I think I would have made a mistake here and tried to model the league table so it was cool that they recognised that there wasn’t going to be much value in doing this since it’s not their differentiator. This was a really useful example for helping me to understand what the core domain actually is.
  • Although the database is not the model, Phil pointed out that keeping the database near to the model helps save the need to do lots of context switching. Interestingly he also pointed out that it’s not always good to completely normalise data – it can lead to expensive joins later on.
  • One idea which I felt wasn’t completely explained was that of injecting repositories into domain model objects to get access to some data rather than having to do a traversal by accessing it through other means. Phil said this was considered a bit of a hack but was sometimes a good choice. He did also point out that it can hide problems with the model.
  • Future plans for the code include adding domain events and trying to create a less monolithic domain – there is currently a single shared context which makes it difficult to prise stuff that’s not in the core domain away.

Written by Mark Needham

March 14th, 2009 at 2:23 pm

Posted in QCon

Tagged with , ,

  • Liam McLennan

    Wow, “injecting repositories into domain model objects”. I wonder how that decision affected their testing?

  • Phil Wills

    Injecting repositories into domain objects, (I can’t think when you’d actually ever want to do this with anything other than entities) doesn’t really have much of an impact on testing. We use builders for all our domain objects and inject a stub repository (in practise we use the lovely Mockito for the stub) by default. It’s easy enough to specify through the builder if you want to use an alternative stub/mock if necessary to test behaviour.

    Looking back on the talk, I probably should have made it clearer that the point was more that I think there’s a risk of being dogmatic about the implementation when what matters is how you can make your code reflect the shared model.

  • André Faria Gomes

    Yes, “injecting repositories into domain model objects”, that’s something that I can’t imagine how to do in practice, but I really want to.

    The problem is: without doing that (having repositories access in the domain model) we sometimes fall again in anemic model problem, putting behavior in different classes of the data, and so on.

  • Pingback: Matt McAlister » Response to the Open Platform launch

  • Pingback: Pigsaw Blog » Blog Archive » Bookmarks for 26 Mar 2009