This is by no means a summary of Eric Evans’ talk, only my main take away and some thoughts it triggered.
I have to admit that the term Domain Driven Design was a bit fuzzy and this talk did a good job at clarifying what it means. Essentially it means that when you build software you effectively build a domain model as well (whether implicit or explicit) and that you should pay attention to that.
In particular, the domain model you build is partial on the domain itself. It reflects some of the views you (and hopefully) your users, take on the domain. It serves the specific purpose of building a shared representation of the domain with your users. All that circled back neatly with agile and embedding the customer and all those good things.
Also I cannot pass over the row boat analogy through which Eric Evans helps explain why agility works more easily on small teams (he noted that boats have a maximum of eight rowers, in part because rowing requires perfect synchronization and that a single miss by one of the rowers throws everybody off rhythm). I would add a few notes to that. It is interested to note that boats of two and four are self organized whereas for eight someone needs to call the cadence. I would also like to reflect that it does not mean that boats of more than eight cannot exist (see the antiquity’s galleys). Just that to make them faster than eight will require a lot of training and that it may be difficult to assemble the individuals that fit together and that it may require more non rowing team members (who thought dead weight ?).
There was another greatly useful analogy with athletic relays which illustrated one pitfall of over engineering system interfaces but it would be too long to explain here. The core of it is that you should engineer an interface that the other system will be able to handle reliably. If it is a csv file exchange then so be it.
Anyway, a final point before the presentation was interrupted by a fire alarm, was that there will always be multiple models of the same domain. That these models are more or less compatible and that you may need to translate between them. As it is, I have first hand experience in that with FpML, Calypso and others and I will add this, if you need to translate your model into another, make sure they are not too different or it will cost you a lot of time and effort which is exactly what you are trying to reduce by defining your domain specific model.
What is the link with strategic design in all that ? Well the premise that not all of a large system will be well designed. Therefore make your domain model explicit helps focus on the core of the system. If peripheral parts of the system are not as well designed, it is not so important.