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.