Bounded context

1

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.

2 Likes
2

Hi,

I am not a DDD guru, but I’m still not convinced that bounded contexts are necessarily a consequence of object-oriented modeling (although translating objects between bounded contexts probably is).

The Ticketing concept from your example is an elegant solution to the “false cognates” problem, as Eric Evans calls it, but it only works if everyone means the same thing by Ticketing. If, for some reason, we end up with two different Ticketing concepts, we are back to the same problem. In fact, that’s exactly what happened with the Charge object in Eric Evans’ own example. Yes, Charge is an object, but the real issue lies in its purpose (billing customers vs paying vendors), making it a conceptual problem. We are then faced with essentially the same questions: Should we reconcile the two concepts into one, or are they serving different purposes? Or would we be better off with two distinct conceptual models, introducing bounded contexts once again?

In that case, isn’t the real question not conceptual versus object-oriented modeling (concepts surely win :blush:), but rather how we deal with different contexts (how to share concepts)?

3

Hello. Yeah, I’ve joined to concur that DDD is not OOP-specific. There’s a great book called Domain Modeling Made Functional. The ideas from this book and concepts complement each other beautifully.

4

Welcome @stoycho and @Alejandro !

I’ve read much of the functional DDD book, and I agree that DDD does not present itself as exclusively OO. And the standard DDD patterns (eg anti-corruption layer) may well be independently of OO.

My point is that the motivation for bounded context and the way that Evans and Fowler and others talk about it is all about OO. Here’s [Fowler](Bounded Context) for example:

Early in my career I worked with a electricity utility - here the word “meter” meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty). These subtle polysemes could be smoothed over in conversation but not in the precise world of computers. Time and time again I see this confusion recur with polysemes like “Customer” and “Product”.

This strikes me as confused. The words don’t really mean different things to different people. Everyone in a company understands what a customer is. The point is that they care about different behaviors and properties of customers. That shouldn’t be controversial, but it becomes controversial when you identify “customer” with an OO class.

Here’s Fowler again:

Bounded Contexts have both unrelated concepts (such as a support ticket only existing in a customer support context) but also share concepts (such as products and customers). Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration.

I think he means individuals, not concepts. The support tickets are individuals that only exist in one context. Different contexts only have different “models” of these individuals if you think in OO terms. In concept design terms, different concepts attach different behaviors and facts to the same individuals.*
*
I wonder if the core problem here is that DDD doesn’t have a coherent notion of what it would mean to have a “model of a concept”, since all you have in a bounded context is either an object/entity or the whole domain model. Perhaps aggregates are intended to address this, but they’re usually talked about in terms of transactions and invariants, not conceptual groupings.

In summary then, I think the idea of bounded contexts is valuable but the traditional justification in terms of “polysemes” etc is wrong-headed and OOP tainted. The hard part as @stoycho notes is how you deal with concepts that are shared across bounded contexts.

1 Like
5

It seems to me that bounding the different contexts is, above all, a matter of integration discipline: “Don’t touch this and this, and don’t even look at that. For others - ask first.”

If I understand Eric Evans and Martin Fowler correctly, the primary motivation for bounded contexts is to prevent teams from stepping on each other’s toes. The real problem is the so-called “false cognates” problem - interpreting the same term differently in different contexts. The “duplicate concepts” problem is undesirable, but I don’t think it is nearly as serious.

What I was trying to find out originally is - isn’t it possible to have the “false cognates” problem also with concepts (in @dnj sense). In other words, is it possible for different teams to interpret the same concept differently, thus motivating a bounding of the different contexts.

Initially, I thought that it is possible. However, after @dnj’s last reply, I realized I had overlooked a few important aspects of concept design.

A Concept is identified by its purpose, and purposes are what define contexts. Different teams can interpret a “Customer” object in different ways, because they want to use it for different purposes. With concept design we don’t have this issue. A Customer is just an individual, and the purpose of our concept determines what we are going to do with the individuals. Once that purpose has been established, other teams cannot really interfere - or at least I don’t yet see how they could. They can either reuse the concept as it is or define a different concept that serves their own purpose.

If that is correct, then concept design does not seem susceptible to the “stepping on each other’s toes” problem that bounded contexts are intended to solve. In that case, bounded contexts would appear to be largely irrelevant to concept design.

Moreover, bounded contexts might even be counterproductive for concept design. If I understood @dnj’s book correctly, concepts are meant to extend beyond software design and become part of the users’ mental models. If the same term leaks out from different parts of the application while implying different underlying concepts or behaviors, wouldn’t that create conflicting mental models for users? In other words, wouldn’t that risk confusing them rather than helping them?

1 Like
6

Oh, I’ve reread the topic, and it’s more nuanced than I thought. I’m writing a blog post on an adjacent subject, but it’s an early draft.

So, basically, we have inherent complexity, and Daniel Jackson’s concepts are a wonderful way to manage it by describing behavior. Then we have accidental complexity, which is captured in the source code and in its history of how we actually made the behavior work.

I’d like to add that there’s data complexity somewhere in between. I presume, when data complexity is not the core of our application, we don’t want to manage it as inherent complexity. It doesn’t fully belong to accidental complexity either, because behavior highly depends on information, although we want to abstract away from it when describing behavior.

And data is not information. Information is what we extract from data to make better bets. Everyone is in a different situation, everyone extracts their own piece of information from data to act upon it.

So, I argue that data complexity is its own part of the whole complexity we’re struggling to manage.

We probably still have to have bounded contexts: first, to manage data complexity within a unit of an organization, because if a context is unbounded it is hard to grasp no matter how smart a person, or a team, or an AI agent is. Second, to manage data complexity between units of an organization or between organizations, because everyone extracts their own pieces of information from it.

Fortunately or unfortunately, to make this communication effective, we have to know our audience, with whom we are communicating. Sometimes we want to give information, sometimes we want to conceal it. We can’t get away from this kind of data complexity, and this is why we need bounded contexts for it.

More concretely, the mentioned book called Domain Modeling Made Functional is about combining DDD with FCIS, which is Functional Core, Imperative Shell. It’s about data flow across systems, essentially. In statically typed languages it’s done using structs. Or in Clojure, for example, it’s done using data contracts called specs. We have to manage this complexity at all layers of our onion and between onions.

I’d be happy to be wrong, so this is more of a question whether this makes any sense.

1 Like
7

Fighting complexity is a good reason for modularity, but I don’t think it necessarily requires rigorous, explicit bounding.

“Ubiquitous languages” form naturally, even in contexts as small as a ticket raised for a bug. That is a good thing, and I think we should continue to be aware of and discern between different contexts.

My idea is still just an idea, open to discussion, but if I’m right that concept design can make the possibility of harmful interference, as well as the cost of misunderstanding, relatively negligible, then the conditions in the “environment” in which we model software do change. The urgent need for self-protective reflexes is no longer there.

The motivations behind Bounded Contexts still hold, but there may no longer be a need to define their boundaries so explicitly. Moreover, as I mentioned in my previous post, we may need better understanding of and visibility into other contexts, to avoid the kind of confusion in users’ mental models that I was talking about—where the same terms imply different behaviour behind the scenes.

If that is the case, we are likely to witness an evolution in the forms of software modelling. Who knows, these may well be the last days of Bounded Contexts as we know them. :slight_smile:

I’m freely speculating here, but perhaps the DDD idea of a “Published Language” could become more important.

1 Like