I think that DDD’s bounded context addresses a problem that concept design solves in a simpler way. Let me know, especially if you’re a DDD guru, what you make of this…
There are two reasons for bounded context:
- It’s too hard to get teams across an enterprise to agree on data models, so better to let them develop them independently and then translate later;
- More fundamental: an object means different things to different teams. See Fowler’s example: obviously terms like “product” and “user” mean different things in sales and support.
The DDD folk use fancy words like “polysemes” to talk about how different teams use the same term for different things. I’d always focused on the first rationale, perhaps because of the typical tendency we all have to interpret ideas in terms of our own. The second rationale just didn’t seem to make sense.
Now it occurs to me where the second rationale comes from, and how concept design offers a simpler solution. If your data model is object oriented, then a user has a username, a display name, an email address, some support tickets, registered products, and so on. Getting agreement on this long list of attributes is of course a fool’s errand, and DDD is right to disavow it.
But suppose instead that your conceptual model is oriented around activities (as in concept design) and not objects. Then you have a Purchaser with registered products; a Customer with support tickets, a Correspondent with an email address, a User with a username, and so on. In concept design terms, these are the parametric type parameters of the concepts. So, for example, a concept for managing tech support might be declared as
concept Ticketing [Customer]
state a set of Customers with a set of Tickets...
and when concepts are composed with reactions (aka syncs), a customer, purchaser, user, etc will all be same individual, represented by a single identity.
In short then, it seems to me that the need for bounded contexts and translating objects is a cure for a self-inflicted wound, namely the presumption of object-oriented modeling. I recently wrote a paper about this, but didn’t realize at the time that bounded context might be added to the long list of technologies invented to undo the problems of objects.
A more serious problem with bounded context, perhaps, is that it hides when you have genuine concept sharing across teams. How will you discover that all your teams have implemented their own versions of notification, authentication etc if you don’t attempt to create a language that is shared across teams?
This gets us back to the first rationale for bounded context. Perhaps an enterprise-wide conceptual model is actually viable, but only if it’s limited to the concepts that are truly shared.