Eric Evans: What I've learned about DDD since the book

[@ErnestLebedev]

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.

[@craigshea2930]

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.

[@kayvankazeminejad9992]

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.

[@notprof]

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

[@andypandy6063]

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?

[@subhashbhushan9219]

Identifying and sticking to the core domain in the example that you give is pretty straightforward. But people can wander away from their core domain in subtle and innocuous ways. A good indicator of this mentality is the Not Invented Here (NIH) syndrome. People tend to get into deep rabbit holes, with seemingly apparent and solved problems like Payment Engines, Authentication, Messaging, etc.

[@Zhuinden]

You think it's obvious, but people often have no idea about how the software they are developing is applied, they just get some random input from management and hope what's being written is what the customer actually needs

[@MrBct524]

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

[@aledmb]

+naresh dhami this talk is for the people who have read his book... he's not trying to teach you the basics.

[@teckyify]

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