The first thing I learned about domain-driven design was “ubiquitous language”: the idea that the business users and the developers should work together to create a common language to describe and model a domain. You’d use that language in the spec and in the code. You’d use it to drive your design, elegantly expressing and solving your business problems.
It sounded like a pretty good idea. But I don’t know how well it can work yet, because I’ve only seen it done poorly.
Here’s a way I’ve seen it done (and done it) poorly: Trying to create a single, unified model that will work for a large, diverse set of functionality.
It’s hard to create a model for a large domain. It’s hard to make one model that works for everybody. It gets harder as the size of “everybody” increases. Details from one subdomain are irrelevant to another. Or just slightly different. But every detail is in there. Because everything is in there. This introduces complexity and confusion and pain.
Bounded contexts are a solution to this. More simply put: Use multiple models. Use a model that makes sense for a given context. Don’t try force everything into a single model.
A model, after all, is useful because it helps your brain: It helps you think about only the details relevant to the problem at hand. When details are included that are irrelevant to the problem at hand, the model stops being so helpful.
With bounded contexts, you might have a half dozen models different in your domain, with a notion of Customer in each and every one of them. And that’s fine. Each of those Customer models should be tailored to the needs of that context.
Yes, that makes your “ubiquitous language” less pervasive, but your ultimate goal isn’t to have ubiquitous language, it’s to build good software.
And, yes, you have to identify what your bounded contexts should be, how to split your domain up. That’s part of designing your domain.
(And perhaps you can benefit from it beyond just designing a useful domain and domain language. I would think the descriptions of those bounded contexts will end up looking a lot like high-level descriptions of the business problems you want your software to solve.)
