Why I don't need a Bounded Context

[Herman Peeren]

DDD practicioners proudly call themselves “domain linguists”. There is much emphasis on the words we use to describe a domain: language is essential for understanding the subject, defining problems and solutions and communicating about it. But what about our own domain: DDD? We have our jargon with fancy words like “ubiqitous language”, “bounded context”, “value object”, “aggregate root” or “event sourcing”. Is their meaning precise and consistent? Are there any redundant concepts? Do they always serve the goal of communication well? Or can those basic tools be improved? In part 1 of this series I investigate the concept of "bounded context".

 

Definition of Bounded Context

In his Domain-Driven Design Reference (current latest, from March 2015, page vi) Eric Evans defines a bounded context as: "a description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable".

This is an odd definition. The adjective "bounded" gives the impression it is a kind of context: a bounded one, as opposed to an unbounded one. This "definition" however states a bounded context is a description: a description of a boundary. I'd not call that a "bounded context", but a "context boundary". The context was mainly called "bounded"  to emphasise that it has boundaries.

A context is a model

When you describe (selected aspects of) a domain, you are modeling. The choice of what aspects you select is part of the modeling process. To describe a domain you need a language. Using language is modeling: the words you use are always an interpretation of what you describe. That language, used in modeling, is what is called the "ubiquitous language" in DDD. It is the language of the model, an intrinsic part of the model.

If you have a domain and a model of that domain, then what is that context in which the model is applicable? It cannot be the model itself, for that would be a circular definition. So it must be something wider than the model for which it is a context. I always saw a "bounded context" as a part of the domain. But when you are describing that context and its boundaries, you are describing the domain... and so you are modeling. You cannot describe the domain without modeling. The context is a model too. The boundaries you describe can be boundaries that exist in the domain, but even if that is the case, the boundaries of a context are always an interpretation, a desigh choice: you describe the boundaries of a model.

Occam's razor

So we have a (domain) model and an outer model, called the (bounded) context. That outer model is used to define the boundaries of the inner model. Let's apply Occam's razor to clean this up a bit: if I define the boundaries of my domain model, I don't need a (bounded) context. I have a model and that model has boundaries. That's it. I can clearly communicate that to all stakeholders using the model. There is no advantage in using a  "bounded context" besides the domain model.

 

Ubiquitous language

How ubiquitous is a "ubiquitous language"? It is only applicable within the boundaries of a model. That is why I use the word "model language" instead of the fancy expression. Something that can only be used within limits is a bit the opposite of "ubiquitous". It emphasises that the language is used by both the technical and non-technical modelers. But the use of that word is not very beneficial for the communication in my experience. We only have to convince the whole team to use a common model with a common model language. This language is only defined and applicable within the (domain) model. Our model is the context for our model language.

 

What's in a name?

You might say that the exact words don't matter, as long as we can satisfactory use our current DDD language to communicate about modeling domains, as we are doing for over a decade now. What's in a name, anyway? But because language is the carriage of our thoughts, according to the linguistic relativity theorem even influences our thoughts, we might improve our analysis, ideas and communication by improving our language. Especially when communicating with non-insiders in the DDD jargon.

[Alexander Morozov]

Have you read "Implementing DDD" and "DDD distilled" by Vaughn Vernon? Here is another more clear definition of "Bounded Context" concept:

A Bounded Context is an explicit boundary within which a domain model exists. Inside the boundary all terms and phrases of the Ubiquitous Language have specific meaning, and the model reflects the Language with exactness.

воскресенье, 28 августа 2016 г., 18:46:15 UTC+3 пользователь Herman Peeren написал:

[Herman Peeren]

Thank you for your feedback. Yes I've read (and analysed) those books too and taken into consideration while writing my text.

Vernon's definition, like Evans', states that a Bounded Context is a boundary, not a kind of context. It is a bit less vague in so far that it states that a Bounded Context is a boundary, not a "description of a boundary", but still the term "context boundary" would fit that definition better than "bounded context".

The main point of my posting is: what is described as a "bounded context" are the (explicit) boundaries of a model. No need for the superfluous and (especially for non-insiders) confusing term, just focus on the boundaries of the model for clear communication. The language that is valid within the context provided by those boundaries is the language of that model. I call it the "model language". Exit another piece of unnecessary jargon ("ubiquitous language") that is not contributing to better communication, especially with people with domain knowledge but not a member of the DDD sect.

[Derick Schoonbee]

Just some observations based on **my** understanding:

When you bring into consideration "Problems Space" and "Solution Space":

To me then "model language" looks like it belongs only to the Solution space (the model) where as "domain language" (used by domain-experts) would be the terms use to express requirements/problems we try to solve (problem space). The term "ubiquitous language" is an agreement between parties from both the "Problem" and "Solution" spaces since it's "being everywhere/omnipresent". A "ubiquitous language term" (part of the controlled vocabulary/thesaurus/ontology) has meaning within a specific "described context/bounded context".

As for "bounded context" vs "described context":
"Bounded context" just feels more precice when I look at dict.org (From WordNet sections)
"bounded" : "having the limits or boundaries established [syn: bounded, delimited]
"context" : "discourse that surrounds a language unit and helps to determine its interpretation [syn: context, linguistic context, context of use]

[Herman Peeren]

Very interesting to bring up the supposed difference between Problem Space and Solution Space for a Bounded Context. It has been done several times in this mailing list a.o. by Alberto in https://groups.google.com/d/msg/dddcqrs/csFiUZU3fMM/R6FNTxiVEQAJ and in DDD literature, a.o. in Scott Millett's book on page 85 (at the end of the part about the difference between a Subdomain and a Bounded Context).

But I disagree with that for a fundamental reason: it touches the core idea of DDD that (within boundaries) we have only one model that is both used for  implementation (the solution) and for describing the domain (the problem). Evans'chapter about Model-driven Design is just about this: "Tightly relating the code to an underlying model gives the code meaning and makes the model relevant". A model is made from two sides, both by describing the domain (Problem Space)  as by coding (Solution Space). Both will influence the model. To quote Eric again: "The code becomes an expression of the model, so a change in the code may be a change to the model". The idea is to start coding from the model, but because coding can give new insights into the model the model should be changed accordingly. Resulting in one model with one language (hence called "ubiquitous").

The dichitomy between Problem Space and Solution Space endangers the common model for both describing the domain and providing the solution, which is one of the most powerful concepts in DDD.

In my terminology a model is bounded (has boundaries) and forms the context within which the model language is valid. Said otherwise: the model is the "bounded context" for the language used in that model. There is no extra thing besides the model that forms that "bounded context"; it IS the model.

[Herman Peeren]

On Monday, 29 August 2016 17:18:54 UTC+2, Derick Schoonbee wrote:

As for "bounded context" vs "described context"

Question: I did not hear the term "described context" before. Maybe I've read over it. Who used that term and how was it used? Why did you bring it up here?

[@yreynhout]

Random thoughts that are probably a tad off topic ...

It's nice if you can reason from a clean slate and dare I say in a somewhat abstract way - yet, in the reality we live in, things are messy and the time to clean that mess up is limited. Boundaries are useful to delineate where one thing starts and another begins - even boundaries themselves can be messy, hard to uncover or require a serious amount of translation. Time and time I have seen how installing boundaries brings down the cognitive load, how it stops people from conflating terminology, concepts (being able to point such things out) and generally making a mess of things. That to me is the general meme and a difficult one it is to get right mind you (similar to soa, µsvc). Most of the time we're not so lucky, as the "one model" we'd like to end up with, that is the "bounded context", just happens to collide with that rotten, stinking piece of legacy software. Life (or money) is often too short ...

Not all problems are equal, and not all environments (I wanted to use the word context but then we'd get side tracked) in which problems live are the same. Some require bringing the problem and solution language closer together because frankly people on both side of the table seem to have a different agenda - often the reason why DDD is brought in. Other times the problem space is of such a niche difficulty that we need to lean on domain experts and adopt their language for a while, until we can make it our own and even get a feeling for when there's ambiguity or something implicit. We may have to come up with new terms or accept synonyms. That said, I've also witnessed people going overboard with the "cause the domain expert said so". Getting language right, again, not an easy rope to walk ...

When people say "a model of a domain", they actually mean "here's a bunch of useful abstractions we can all reason about and compose in such a way that these n domain specific scenarios are solved". The size of the domain covered (if at all relevant) will be determined by the scenarios (there is a correlation). Not only that, but there's not "a model", there's n models, of which we found 2, maybe 3 (optimistically speaking), and a bunch more we may not have found (for whatever reason). Some models are a nice thought experiment but seem hard to work with in code, hence why this probing step is often necessary. Mapping to technology, patterns, programming language sometimes gets in the way.

Personally, I've moved on from the battle that seems "getting the definition right".

[Derick Schoonbee]

Sorry, was biased in my thinking ;) Should have been "description of a boundary".

[Herman Peeren]

Thank you for your (on topic) feedback and experiences "from the trenches".

For me discussing the DDD-vocabulary and coming to more clear definitions is not a goal in itself. The butcher and the chef are sharping their knifes before cutting, not because they are fond on sharp knifes as a goal in itself, but because it eases the work. Language is our main tool and I'm trying to sharpen it a bit, hoping to ease the difficult job of modeling our fuzzy and complex reality.

We agree on boundaries being useful, but often hard to uncover. What I'm trying to sharpen in this posting is that we are talking about the boundaries of a model and that we should try to make those boundaries as explicit as possible while modeling. That is nothing new: that is exactly what has been said for more than 12 years using the term "bounded context". I only want to sharpen it a bit by showing that that is not a thing of its own, besides the model, but that we are talking about the boundaries of a model. "What's in a name?" expresses how unimportant it is to just give another label to some thought and it relativates this effort to clean up our language (and get rid of unnecessary concepts), but I think this is useful.

My effort also comes from some experiences with the already difficult communication with technical and non-technical people in one team that was hindered a bit extra by the (over)use of DDD jargon instead of focussing on the domain. I don't say the domain experts are always right, neither are the technicians, but that the power is in the communication and in the common models of those 2 groups.

[@yreynhout]

I doubt getting crisper definitions is going to make you a better modeler TBH. It might bring more clarity in peer to peer communications, no argument there. Examples of boundaries are teams, departments, source code repositories, folders, contracts, etc ... I would hardly call those "the model", rather the seam we impose or that has grown organically. I keep on repeating this: the model is the set of abstractions you come up with to solve a particular problem or set there of, where the language is consistent and unambiguous.

Rule number 1 of the DDD fightclub? Don't talk about the DDD fightclub :-)

[Herman Peeren]

We want to build models where the language is consistent and unambiguous. To train being precise and to improve communication in teams I participate in I want to "eat our own dog food". Horrible non-definitions and foggy concepts don't contribute to that and are bad advertisement for the otherwise powerful concepts of DDD. Maybe I'm a bit hypersensityve in this area, influenced by language philosophers like Gilbert Ryle, who dissected and deboned language with such a precision that we can learn a lot from it... but, as you rightly stated: "Life (or money) is often too short".

BTW, for me the sentence "Examples of boundaries are teams, departments, source code repositories, folders, contracts, etc " is an example of imprecise use of language: teams, departments, source code repositories, folders, contracts, etc are not themselves boundaries, but different teams etc. are indications that different models should be used, so one model should be worked on by one team and /or be based on the responsibilities of one department, should not be in different code repositories etc. Those divisions "in real life" are possible indications that a monolith model should probably be split. Not more, not less. Looks clear to me. No need for an extra concept for that, for it doesn't add anything.

I don't say anyone has to do as I do or agree with me, but I see advantages in cleaning up the DDD jargon for teams I work with. I don't fight, I only started showing my conclusions. Part 2 will be about a better word for Aggregates and part 3 about Value Objects. In the mean time please continue modeling your ARs in BCs ;-)

[Kijana Woodard]

I was leaning toward's @Heman's point of view until I read @yreynhout:

> Examples of boundaries are teams, departments, source code repositories, folders, contracts, etc

I realized that I was giving to much credence to the _code_. 

In a well functioning organization practicing DDD, I'd assume that everything from the Marketing, the Legal Contracts, the Sales scripts, the Support chat scripts, the Email auto-responses, etc, etc all key in on the Ubiquitous Language.

> but different teams etc. are indications that different models should be used

Not sold on that point. Not sure why, in an age of Pull Requests, that team === model.

Further, I agree that "different teams" is an indicator, but it may be that the teams are misaligned rather than the model.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Herman Peeren]

I think you misunderstood the points Yves and I disagree upon and were discussing. We don't disagree about basic DDD-ideas like divisions "in the real world" being a possible indicator of another model (or another Bounded Context in DDD jargon). I'm not saying anything new here, I'm just trying to improve the DDD vocabulary to be more precise in modeling.

From Yves' remarks I a.o. learn:

• He doubts if my efforts are cost effective: it's a lot of trouble getting definitions sharper while it might hardly yield better models. Yves has a lot of practical experience while I am inclined to more academic discussions.
• My concept of a Model might be a bit broader than his: in practice we have to focus on solutions and deliveries, which limits the time to elaborate on modeling the domain more broadly. When I state "when you are describing the domain, you are modeling", that is a more abstract ("academic") view on modeling, while in practice what we call modeling is part of finding solutions.
  

On Tuesday, 30 August 2016 17:17:29 UTC+2, Kijana Woodard wrote:

I was leaning toward's @Heman's point of view until I read @yreynhout:

> Examples of boundaries are teams, departments, source code repositories, folders, contracts, etc

I realized that I was giving to much credence to the _code_. 

In a well functioning organization practicing DDD, I'd assume that everything from the Marketing, the Legal Contracts, the Sales scripts, the Support chat scripts, the Email auto-responses, etc, etc all key in on the Ubiquitous Language.

If I understand you right, you are thinking a Ubiquitous Language would be used in several models (= in several Bounded Contexts), but this is not the case: the Marketing model uses another language than the Sales model etc. This is also a nice example of how confusing the word "ubiquitous" is: it is not ubiquitous across models, but only within the boundaries of a model (or, to say it in DDD jargon: within the Bounded Context).

 
On Tuesday, 30 August 2016 17:17:29 UTC+2, Kijana Woodard wrote:

> but different teams etc. are indications that different models should be used

Not sold on that point. Not sure why, in an age of Pull Requests, that team === model.

Further, I agree that "different teams" is an indicator, but it may be that the teams are misaligned rather than the model.

Yes, it is an indication of a possible boundary. A team can remotely work together (although then I often see DDD-concepts less used due to the less direct communication). But this was not the point of discussion.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

[Thomas Schanko]

Trying to kick in with just some quick thoughts as it is already getting late:
Bounded Context is at least close to a tautology because obviously a context cannot exist without a boundary. The boundary defines the content, if you will. On the other hand, Using just the word context to name and describe a concept like the one under discussion would be impractical. One would simply not get the meaning of the word context without knowing the context of the conversation.
But, as this is more about the words than the concept they try to communicate, you could have used a titel like 'Why I don't like the term Bounded Context'
That's the samw way I feel about 'Microservices' (almost)

Thomas

[Andrew Siemer]

I mostly stopped writing c# very recently. And then I found that I talk about ddd much less. A bounded context is now simply a logical collection of microservices (AC/runtime). A microservice is a docker container hosting a node app or when possible just a couple of lambdas. The BC may have some shared data store between the services. Nothing more to talk about really.

...so now we talk about how many repositories for code are needed, branching strategies to support ci/cd, ci/cd, and ensuring a resilient fault tolerant production environment...so we can ship product quickly and simply.

Node ftw!

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

[Herman Peeren]

@Thomas: you are right, but I deliberately formulated the title a bit stronger (and maybe a bit more challenging too) because besides not liking the words I also want to say it introduces an unnecessary concept, as if a Bounded Context would be something besides the model, whereas it is the model that forms the context and that model has boundaries.

[Herman Peeren]

@asiemer Interesting to see that Node fits your software production better than an OOP-centric language. Maybe some of the concepts of DDD were merely a fix for shortcomings of OOP, just like for instance GOF Design Patterns are not/hardly needed in functional languages. I still think that any complexity in the problem space needs good modeling skills and that is independent of the implementation languages and tools used.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

[Thomas Schanko]

Ok, let's sharpen our knifes and dig a Little deeper. Starting with the old trueism" All models are wrong, but some are usefull", I'll come up with the following:
There is no such thing as "the model". At least, no unified model of a domain. As we divide our problem space, we come up with multiple models in the solution space. Each with just enough detail to describe and solve the problem at hand. As you said ,those models have boundaries. But I don't think that the model forms it's context or boundaries. Instead, we have to come up with an idea of the context (let's say some assertions) before being able to form a model.
Looking at the solution space, a bounded context could be thought of as a set of assertions (maybe preconditions) building a stable ecosystem for the model (other aspects or motivations like team boundaries left alone).
Building a complex system by composition of smaller subsystems we are effectively designing interactions between bounded contexts. How do we align this with the solution space? While there is a lot about the organisational relationship between bounded contexts in the blue book (context map), there is barely nothing about interaction.

[@yreynhout]

Honestly, to me they are boundaries. Not as in "always" but depending on the environment I've encountered them in. No amount of you saying "no they're not" is going to change my mind nor make it so objectively. It's still your subjective perception of things, which I respect, don't get me wrong. I've experienced all of these boundaries first hand - try some enterprise development with egos and you'll soon find out that teams quite literally become the boundary. Boundaries sometimes tell you nothing of the model(s) that lies within. I've installed some of these boundaries, just so one can actually scale development or be able to move people/budget around. Strategic design often translates to money, opportunity, responsibility, authority, communication, etc ... and bounded contexts make that conversation easier without the need to talk about the intricate details of the models in each and every one of them.

I don't see the advantage in cleaning up the jargon if it means redefining it - clarifying, sure, redefining, nope. To me, that does more harm than good, but you're free to have a different opinion ... and that's all I have to say about that.

[Herman Peeren]

Yves, I totally agree with you that teams mostly form boundaries. That however was not my point of discussion. It was only about the exact wording of that.

When I said "a team is not a boundary", I meant it in the sense of defining some specific thing in more general terms. Like "a hammer is a tool", where a tool is the more generic term and a hammer a specific kind of tool. Or "a team is a group of people working together", where "a group of people" is the generic term and "a team" a specification of that. In OOP inheritance jargon you could compare it with a parent class or interface being the more generic term and the derived or implemented class being the more specific one. Teams form boundaries, obviously, no doubt about that. But I see it as boundaries of a model, where a model is defined as some abstraction of the domain using a consistent language.

I'm not redefining anything with that. I'm only looking at the meaning of some words. I noticed that the use of the term "bounded context" often has some infinite regress: it is defined as a boundary in which the model is applicable.... and then I read sentences talking about "the boundary of a bounded context" (for instance Millett's book, end of last line page 82).