We spent a lot of time discussing domain events - one of the new ideas which Evans had observed since publishing the book - and Liz pointed out that a domain event often exists where there is some sort of interaction between objects which doesn’t seem to belong on either object. The example Liz gave is where there is an accident between two cars and we realise that there should be a Collision object to describe what’s happened. Dave pointed out that commits in Git could be another example of a domain event. We discussed some domain events which we had noticed in code bases we had worked on. One system I worked on had the concept of transactions to describe interactions between different accounts. They were also used to calculate the balance of an account at any time in preference to keeping the balance of each account updated in real time. The balance on the account would still be updated at the end of each day such that we would only need to make use of transactions since the last update to calculate a balance.

What really stood out for me in our discussion is how a lot of the concepts that Eric Evans talks about are designed to make us explicitly state what we are doing in our code. We have domain events for describing what happens in the domain, we try to define bounded contexts so we know what the object model means in specific areas of the code, we identify a core domain so we can spend our time on the most important code and so on. Dave described this as conscious coding in that it makes us think very carefully about what we’re coding rather than just coding without real analysis and probably writing code which isn’t as useful as it could be.

I’m still not sure that I really get what the core domain means but Dave described it as 'If we stripped out all the other code in our system except for the core domain we would still be able to build something around that' which actually has the side effect of pointing out that we need to ensure that this code is completely decoupled from any implementation details of the current way we are using it. For example if we are currently writing a website and it is decided that we need to be able to display our content on a mobile phone, we should still be able to make use of the same core domain code to do that fairly easily.

The section of the talk about the big ball of mud and the green house was also very interesting and Raphael Speyer came up with the analogy of only letting code from outside the green house inside if it had been hosed down and all the mud removed so that we can ensure that out important code is of comparable quality. If I understand correctly the core domain is the code that should reside in that metaphorical green house and we will spend a lot of time on its modeling so that it will be easy to change in the future. By contrast the modeling of the code outside the green house is not as important - a lot of the time the code out there is 'just data' and we want to display that data to users with minimal effort in modeling it in our code since we don’t get a great deal of value from doing so.