Depends on whether you’re talking about the DDD meta-language or a concrete, well-defined language for a particular domain. I have absolutely no problem with the latter, but I do have a problem with the expected ubiquity of the former :)

I'm in the opposite camp. The DDD language is a pattern language in the true sense, designed to _democratise_ the domain, in the same way Alexander's was intended to democratise architecture. It's a small, easy-to-learn vocabulary that enables enthusiasts to communicate.

Is it easy to learn though? Because as someone interested in but not very knowledgeable about DDD... I didn't find them easy to learn. Still don't, still working on that.

DDD in a tweet: 1. People in the same job, or domain, use similar words. Work with them to find that language. 2. Different domains use different words. The words are only valid in that context. 3. Be consistent with the words within a domain. 4. Identify the context boundaries.

I once worked in the domain of driving licenses. This was a nightmare as there were multiple domains using the same works for slightly different things. a "qualification" for normal driving licenses was similar but not the same as qualifications for e.g. "taxi".

This issue is specifically discussed in DDD and is what the concept of Bounded Contexts focuses on. BTW if you want a really fun one to watch unravel into a mess ... try "trade" or "position" in a financial house :-D

I'd argue its more to it than just bounded contexts. as all of this is described as actual laws. some are shared across the contexts, some are not. One could say shared kernel maybe, but I found this domain very fluffy and things tangled together through the contexts.

like multiple circles in a Venn-diagram overlapping in all sorts of ways

One useful technique I've discovered is to think of a _business process_ or activity as the bounded context, rather than a bunch of related entities or a department. So the vocabulary within the subdomain of _driving license application_ is consistent. Ditto _taxi licensing_.

I like this style of top down thinking. I like to focus first on process managers/sagas. Let's map out what the *big business process* is then look at what messages it uses These bigger processes can be hard to analyze to start in some places though (compartmentalization)