Hi Vaughn,
I'm not yet using DDD in my daily job but I sure hope that, as a consultant, I once will have the opportunity to do so as I'm very interested in the topic.
In fact, I am so interested that last month, I followed a three-day course that went out from DDD Europe. I can only advice others to do so as well.
I also have a copy of your book Implementing Domain-Driven Design; I know much more about cowboys now! But I admit: after long working hours, my brain tends to go in overdrive when I read it.
My question is the following;
One of the purposes of DDD is to bring technical (accidental) complexity to a minimum - which is great.
But DDD is not something that you can just pick up just as with a technical framework, by reading a third of the documentation, yell HASHTAG YOLO, and then jump right in.
I think I am aware of all the advantages and benefits that DDD brings, but my gut feeling (the feeling of someone that is new to DDD) is that the threshold of doing it CORRECTLY looks much higher than dealing with any other technical complexity created by bad design decisions with concepts that we know.
When we trade that for something where the only answer to our questions can come from someone with a deep understanding of DDD topics like Bounded Contexts, Aggregates, Roots & Services, ... That frightens me!
What is your advice to people starting with DDD in their projects?
And related, what is typically a good way to start venturing out into the world of DDD?