Getting to DDD: Pragmatic or Principled? - Julie Lerman

Domain-Driven Design is a vast topic. There are so many wonderful concepts, philosophies, patterns, practices and techniques to learn and benefit from.
Some of the best minds in the industry have been tuning these practices for years to ensure developers are able to implement proven, successful approaches to software design. Domain modeling in particular is very specific with guidance on designing and coordinating the dance between the myriad moving parts in our system. Yet learning the principals of DDD can be daunting for developers who are new to DDD. To encourage and enable more developers to get on the path of DDD, is it reasonable to allow a more pragmatic approach over a principled approach of adhering strictly to DDD guidelines? Should developers be encouraged to start with low hanging fruit which they can quickly benefit from in their software projects while they continue to learn, to gain a deeper understanding of Domain-Driven Design in order to evolve and adapt their practices as they move closer and closer to the beauty we all know that can be achieved with DDD.
Check out more of our talks in the following links!
NDC Conferences
ndcoslo.com
ndcconferences.com

[@goldmund67]

"Kind of people doing database design for 20 years and find it hard to shift..." I've been seen.I found this talk helpful. I read (most of) the blue book. Most of my 30 years of development is database centric. Could never (and still can't) put the two together with effortless intuition because for me the schema is everything...but...similar to you, my epiphany is not EF Core but Event Driven Architecture and Messaging. Another NDC speaker made the comment that physically separate services which intercommunicate via messages gets you half-way to bounded contexts, and that was my epiphany, along with the guidance that microservices should have their own persistance instances.

[@TheAndreArtus]

I think this video would get a better ratio if it was not for the mismatch between the content and the title. If the title reflected the content as "how to sell DDD to people who want it but don't yet know it, for people broadly conversant in the subject", then it would get more love. Could be boiled down to:
* meet people where the are currently at, lead them to where they need to be,
* don't put purity before pragmatism: ideas before terminology,
* don't put purity before pragmatism: pick the low hanging fruit first ( easier to sell the concept of eating fruit when it does not involve a death defying climb at the get-go), purity will come in time as previous benefits are realized.
* Sometimes good enough is good enough (for now). The overall idea is to make building software (and related systems) easier and less prone to mistakes. Programming, much like anything, requires practice and not just theory (learning is a series of controlled mistakes, but you've got to make them). Just because you started with training wheels does not mean you cannot go on to ride races in later life, but trying to master a racing bike before your feet can reach the pedals is probably unwise.

[@JulieLerman]

thanks for this feedback. It was very well received as a keynote at a major DDD conference. It's been disappointing to watch the thumbs downs accumulate here.

[@TheAndreArtus]

@@JulieLerman I think it's the context switch. In the context of a conference where attendees either have DDD knowledge (either prior or from attending) it appears good for what I believe you intended, i.e. a convert selling the idea to potential sceptics may benefit from a pragmatic approach, whereas some of the downvotes are likely from people (willing to learn, but not yet knowledgeable on, DDD) expecting to learn a pragmatic approach to DDD (e.g. a DDD for Dummies or DDD Distiled in video form).
Al large part of the disconnect, in my opinion, comes down to how the video is titled. It's not that the title does not reflect the contents of the tin, it's more that it leaves room for misinterpretation.

[@danielgilleland8611]

The problem people have in understanding what a "ubiquitous language" is is that "ubiquitous" is not ubiquitous to most people's language. It's like - nobody uses it, so nobody understands it.

[@JulieLerman]

Totally agree! I really got annoyed reading things that kept using the term before I was comforatable with it. So again, better to start by *doing* not just *saying*. Define terms that make sense to everyone on the team. Help guide them to use those terms rather than having to "translate". Then people are using a "ubiquitous" language for discussion the domain and eventually let them know that this is the word we use to describe it in DDD. Also keep in mind that it's important to have. ubiquitous langue for discussion DDD related things so eventually it's still important to know those terms. Like me with my problem with remembering that ACL stands for Anti-Corruption Layer. I always balk...first I think "ACL, then I picture the Justice League, then I remember the words. :)