Dan briefly covered some of the Domain Driven Design basics, including quoting Jimmy Nilsson on what it actually is:

Dan described the core domain as being your differentiator (what makes you special), the thing the stakeholders care most about, the place where the most interesting conversations are going to be, the richest seams for knowledge crunching. I don’t think I really understood what the core domain was before watching this presentation - it also helped me make sense of Eric Evans' comment in the previous talk where he spoke of not spreading the modeling too thin, instead keep it focused on the areas that provide you most value.

He spoke of the benefits of having a shared language used by everyone on your team - you don’t have the translation effort which is very tiring! Driving the language into everything has the added benefit of giving you a place to put behaviour, otherwise it ends up spread all over the place. Dan spoke of the ubiquitous language only being consistent within a bounded context - not really so ubiquitous after all!

Next up was the other side of the coin - Behaviour Driven Development. He described BDD as 'focusing on the behaviour of an application from the point of view of its stakeholders', where the stakeholders are anyone who cares about the application. BDD is about outside-in development where requirements are expressed as stories which have acceptance criteria to help us know when we’re 'done'. The acceptance criteria are comprised of scenarios made up of steps and these then become acceptance tests when they are completed. He also riffed a bit about bug driven development - outside in taken to the extreme. Dan made an interesting point that BDD is about a mindset rather than the tools and I think I agree there - I’ve not used the tools much but I try to consider the behaviour I’m trying to drive whenever I’m writing tests/examples.

For a while I’ve preferred to describe the way I write code as being driven by example rather than driven by tests but it is still referred to as TDD - Dan helped me to see how this makes sense. We code by example to implement features but when those examples are done then they act as tests.

Dan spoke of the 'Glaze Effect' when speaking with domain experts i.e. when you talk using language from a domain they don’t understand - probably using language that is too technical for them to care.

Dan said the first part of the book is effectively 'The Hobbit' but the really interesting stuff only comes in 'The Lord of the Rings' which is the second part. That’s pretty much my experience as well - I gained way more from reading the second half than the first half. Dan pointed out that the ideas around scaling DDD are applicable anywhere - they’re not specific just to DDD.

BDD is about conversations in the ubiquitous language to produce software while DDD is about exploring the domain models that stakeholders use. Discovering these domain models can be valuable even if you don’t end up writing any code.

There is a circular dependency between BDD and DDD - we can’t have behaviour driven conversations without DDD and BDD helps structure the conversations you can have in DDD. The structure that the Given, When, Then scenarios provide for having conversations was also identified as being a key part of how BDD can be useful. When it comes to coding, DDD helps drive the design and BDD helps drive what you develop.