kzbin.info/www/bejne/onaZeauwad6io6M wait, what

Bottom line is - focus on strategy (distilling core domain and context boundaries) and don't worry too much about building blocks.

Great talk. This talk validated some things I have come to realize over the past few years, having read the book about 3 times and struggling with some of the concepts. My struggles were rooted in some things he had to say in this talk: Context Mapping and Distillation of the Core Domain are under-emphasized in the book while the patterns portion (chapters 5 - 10) are over-emphasized. The section on Aggregates was also particularly helpful--entire land wars (j/k) have been fought over aggregates, how they're constructed, the use of Entities vs. Value Objects, etc. Thanks for putting this into perspective. Even though the book does say it outright: DDD really does require an iterative process and access to domain experts; this is often overlooked. Without these, you can't possibly hope to get the value out of following DDD principles. Unfortunately, in my experience, I have not had the pleasure of being in an organization where both of these are present. In some of these organizations, they purport to use DDD principles, but it's really a Big Ball of Mud (OK, so that's sort of a pattern ;) ) with an anemic domain model. Although it probably won't happen, I would love to see a 2nd edition of the book, rearranged and with the added material: especially the Partner bounded context pattern, his valuable insights concerning the Big Ball of Mud and how to make the best of it when it's present in the project (and even how to incrementally improve the project despite the Big Ball of Mud), and the addition of more discussion around Domain Events and Event Sourcing. (Domain events were only lightly touched upon--but as Eric alluded to in this video, at the time the book was originally written, distributed systems were not as prevalent due to various constraints of the time that have since ceased to be constraints.) Thanks for sharing this video.

What is this really about Develop in the Domain you are? Isn't that pretty obvious? If you developing a powerplant then maybe you should think in the domain of a powerplant and not in the washingmaschine domain, right?

Honestly, guys: if you didn't get any value out of this talk - that is your own loss, not Evans' lack of precision! Because for those who happened to read his book this talk is like a whole new treasure room that you suddenly procured and you're standing at its threshold, admiring.

I am not impressed by this presentation. I have seen a lot better talks on DDD by experts.

Why is this talk so ridiculously boring, general, fuzzy and vague. That happens when the topic is incomprehensibly huge for a talk.

Excellent. The holy-grail of agility.

nice one. Evolving Agile with the help of DDD, so there is no revolution against it ;).

Oh, ddbgbddvrgfrggbdxyfgus, I think you made a typo in your second sentence :)

Great intro to BDD (even though it's from 2007!).

This was an awesome presentation. I've read the book several times and it was great to see Eric describe the key parts of it.

This is how you make software fun!