RE: How to convince my team to do DDD?

Hi Atle,
 

 I just read your message from a couple of months ago and I wondered if your team is working with DDD?
 I'm also trying to convince my team members to take a look at DDD, but I'm hitting a wall explaining it to them. They just don't see the possible benefits from it. So how did you cope with this? 
 The reading material available (books from Evan etc) has quite a steep learning curve. And I must admit I to had problems to fully comprehend all the different aspects that make DDD what it is. But I've bitten the bullet and expanded my knowledge vastly.
 

 So I'm looking for some tips to help me tackle this little bump on the road :)
 

---In [email protected], <atleh3@...> wrote:

 Hi all,
 
 Just a short update to my previous post below:
 
 I ended up with proposing a common arrangement for reading the IDDD book for the team, and the feedback was very positive! So yesterday I ordered 16 (!) copies of Vaughn Vernon's book, with estimated time of arrival mid next week. We plan to organize this so that we agree on a certain reading progression (one chapter per week, for instance), and then arrange for a tech lunch after each chapter to discuss what we have read. I am a bit excited, both since I haven't tried this before, and also because I may have oversold the book.....
 
 Regards,
 Atle
 
 --- In [email protected] mailto:[email protected], "atle03" <atleh3@...> wrote:
 >
 > Hi all,
 > 
 > I have a clear impression that my team/product could benefit greatly from using DDD, but at the same time I really don't see how I can convince them about this. I am not only thinking of using DDD as a set of patterns for organizing code ("DDD light"), but see DDD more as a behaviour-changing think for the team. For me this means establishing the ubiquitous language, defining bounded contexts, doing collaborative design sessions around the domain model, working with business concepts in code, etc. The dream would be some kind of "awakening" in the team where people see the light and start changing their behaviour.....
 > 
 > Does anyone out there have ideas on how to approach this? Any sources of inspiration I can point team members to? Although the books (Evans, Vernon, Nilsson, ...) are very good, they require some effort to get through, and I find them less suited for convincing "newcomers", especially non-programmers. Other than that, there are few presentations, booklets, videos, articles, etc around.
 > 
 > Regards,
 > Atle
 >