Deeply incorrect definition of BC

[mathiasverraes]

The first line of the readme says "A bounded context is a sub-system in a software architecture aligned to a part of your domain."

This is literally the opposite of what it is.

A Bounded Context is a boundary around a model and its language. Within this boundary, the meaning of terms is unambiguous, well-defined and understood. The model is clear and the rules are consistent. It offers no such guarantees outside of its boundary.

• It's not a subsystem, it might be spread across multiple subsystems. It might not have a physical system, such as an Interchange context.
• It might span multiple domains or only deal with a chunk of a single domain.
• A domain might be expressed in multiple bounded contexts, eg if we purchase a competitor that does similar activities.

This incorrect reasoning lies at the heart of the whole BC canvas and is probably responsible for a lot of misunderstanding in the DDD community.

[NTCoding]

Thanks for raising an issue Mathias. A pull request has been raised addressing the issue. Feel free to leave any comments over there or re-open this issue if you would like to continue the discussion here.

#42

[mattes3]

Well done. Good clarification, @mathiasverraes, thank you so much!

[yellowbrickc]

Thanks @mathiasverraes for raising the subject and @NTCoding for the proposed solution. I agree with both of them 👍
What is bothering me a little bit is the comment "This incorrect reasoning lies at the heart of the whole BC canvas and is probably responsible for a lot of misunderstanding in the DDD community.".

Which misunderstandings do you mean Mathias (because there are several...)?
How exactly is the canvas misleading? Do we need to change more than remove the wrong definition?

[jmquarck]

In my opinion, re-routing people to external resources is kind of surrendering to the goal for this repo of being a complete starting point for teams beginning their journey into DDD, which is as I have been using it for months. I might be wrong about the intent for this repo though.

Unfortunately, it is hard to find a resource online which is at the same time free (I mean, not a book you need to purchase first) and clear. For example, both resources you replaced the former definition with are not either: the Eric Evans site requires you to download a free PDF that it does not include a Bounded Context definition per se. And the Martin Fowler article also points you to other resources (mainly Eric Evans' book).

In my opinion, it is OK to include additional resources to investigate further, but a short, usable definition should be included here. If you asked me, it could easily be extracted from @mathiasverraes comment:

A Bounded Context is one model and its language. Within its boundary, the meaning of terms is unambiguous, well-defined and understood. The model is clear and the rules are consistent. There is no such guarantees outside of this boundary.

With a definition like this one above, it becomes clear that it is the boundary what defines the context, and that changes in meaning are what define boundaries.

For example, a company can be a Qualified Lead for the Marketing team and a Qualified Lead for the Sales team. This same term has different business meaning in Marketing and Sales (in general, a Marketing Qualified Lead would become a Qualified Lead for Sales), so this change in meaning defines a boundary and therefore two contexts: Marketing and Sales.

I hope this helps!

[cjjohansen]

I Like @mathiasverraes definition since its consise and articulates the essential while not beeing to specific. On the other hand a bounded context in a context map is said to represent the current state of things i.e. the implementation or the solution domain. (At least I have heard that recommendation more than once). I think we operate with 2 models here. The mental model of the problem domain and the implemented model anchored in an implementation. These two models are often not alligned. But its easier to communicate when they are.

[yellowbrickc]

I think the recommendation to represent the current state in the context map is related more to how to start using DDD tools, not how to use the context map. If the BCs change, the context map can change too. It could even change because of the team dynamics, IMO.
Regarding the 2 models: I use the same canvas to visualise everything: the current understanding, deprecated or future contracts. Do you feel constrained by the canvas using it like that?
I use the BC canvas a lot, and I would like to know if it is misleading. I don't know what @mathiasverraes sees as wrong, but I would like to know it because, usually, he is right.

[NTCoding]

What does everyone think about renaming it to the "Subsystem Design Canvas"?

If I have correctly understood the concerns being raised, it's that the canvas doesn't accurately convey what a bounded context is. If that's the case we could decouple the canvas from the concept of bounded contexts to avoid the misrepresentation?

[Max-Git]

From my own experience, the confusion comes from the fact that some people tend to think that it's an API design tool for microservices (or any subsystems).
We could keep the name by making sure it's more clear in the description. Regarding the fact that a BC "might span multiple domains or only deal with a chunk of a single domain", we could maybe add a section where we could mention the domains/subdomains where the BC belongs.

[yellowbrickc]

I wouldn't rename the canvas, @NTCoding, because in that case, we would still need a tool to document the Bounded Context 😆 . I think the proposal of @Max-Git might be a good one. Even if I am sure that we can't replace learning with a tool, I agree that the misunderstanding is a real problem and that we never answered it. We have a BCC and an Aggregate Design Canvas, but we have never talked about the relationship between the two.

@Max-Git, I have a follow-up question to understand you better. You mention microservices and suggest adding "domains and/or subdomains where the BC belongs to". I would have expected "services composing the BC" for an ms-architecture or "some structure representing the BC as part of the monolith XY". Do we mean the same or not, actually?

[cjjohansen]

The first line of the readme says "A bounded context is a sub-system in a software architecture aligned to a part of your domain."

This is literally the opposite of what it is.

A Bounded Context is a boundary around a model and its language. Within this boundary, the meaning of terms is unambiguous, well-defined and understood. The model is clear and the rules are consistent. It offers no such guarantees outside of its boundary.

• It's not a subsystem, it might be spread across multiple subsystems. It might not have a physical system, such as an Interchange context.
• It might span multiple domains or only deal with a chunk of a single domain.
• A domain might be expressed in multiple bounded contexts, eg if we purchase a competitor that does similar activities.

This incorrect reasoning lies at the heart of the whole BC canvas and is probably responsible for a lot of misunderstanding in the DDD community.

Hi @mathiasverraes I'm curious on how you will explain the relation between a bounded context and a context map (Notice i dont mean the bounded context canvas here).