I agree that the name took over. The intention sounds synonymous with bounded contexts of DDD.
I find the vocabulary of DDD to have more explanatory power. Especially with people who don’t grok the difference between removing repetition and consolidating models.
I think repetition is a symptom that a code base may be afflicted with interwoven domains, but the existence of repetition is not sufficient for the diagnosis, IMO.
Bounded Contexts is an idea that helps you draw the boundaries between domains. It asks you to be disciplined in your abstractions, and in return it allows you to feel comfortable changing implementations within a domain without fear of cascading second order effects to other domains.
For example, your service/library for managing customers shouldn’t return data about the books they’ve purchased. That comes from the order context, which composes the customer and book contexts.
If your boundaries are well defined, you can change the order process without fear of the book and customer models, and vice versa.
It marries well with service oriented architecture, because you can use the network to help enforce a boundary. You still need some skill to enforce the correct boundary, of course.
> The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"
(from wikipedia)
It feels like the name really took over the intention and it became about code repetition instead of knowledge repetition.