Missing bounded context distillation

[Baasie]

I was going through the process again, and when we get to connect we start talking about subdomains, and then doing domain message flow modelling we use Bounded Context but never about distilling/decomposing bounded contexts. Only decompose subdomains.

Then at Organise we introduce context mapping and teams. But no explicit steps in distilling bounded context right?

Should we add that during decompose? Make it more clear? Alberto in his book talks about decompose/distill into emerging bounded context. What do you think?

[NTCoding]

I believe that in Alberto's book he doesn't talk about subdomains and skips straight to bounded contexts? Are you proposing that here or do you mean add an extra step to distill subdomains into bounded contexts (after decompose)?

[Baasie]

Alberto mentioned he goes straight to emerging bounded context, which is also the concept I use at this stage.

I would propose adding it to decompose, and rename it to decompose & Distill.
IMO we decompose subdomains, and distill emerging bounded contexts

[NTCoding]

I'm the opposite, I use subdomain because I want to emphasise the team is responsible for business and IT - discovery and delivery. I haven't really used bounded context over the last few years and no problems have occured. So it's a bit of a personal preference choice about what words are used to describe the activity. We could just highlight this conflict and say some people refer to this as decomposing the domain and some people don't use the concept of a subdomain and instead refer to it as distilling bounded contexts. In practice all of the activities and heuristics are the same so there are no deeper changes needed here.

…

On Wed, 3 Jan 2024, 13:37 Kenny Baas-Schwegler, ***@***.***> wrote: Alberto mentioned he goes straight to emerging bounded context, which is also the concept I use at this stage. I would propose adding it to decompose, and rename it to decompose & Distill. IMO we decompose subdomains, and distill emerging bounded contexts — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFI67SWKF3HFRCVDNHO5DTYMVNJBAVCNFSM6AAAAABBLIEXRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGM4DGOJVGM> . You are receiving this because you commented.Message ID: ***@***.***>

[Baasie]

Ah we are close to jumping rabbit holes :D....

The problem however IC is that in domain message flow modelling bounded contexts is mentioned and not subdomains. And the litarature out there makes the distinction between the two, which there is. I find it important to teach, but I might not use it during workshops because they have both seperate purposes in my honest opinion.

Now I agree that the focus during Collaborative modellings should not be on the dogmatic. And it is all about the concepts of grouping and taking ownership and responsbiliy so we agree there.

However problems might not be noticible, but there might be confusion because of the ambiguity when people read this and the litarature. So your proposal of highlighting it would be a good first step. And perhaps then see if we need to go further.

[NTCoding]

There's a lot of confusion out there already. People are always asking me what's the difference between a subdomain and a bounded context and I've seen lots of varying definitions for both, sometimes even with business capabilities thrown in as well. Based on my experience, the words are mostly interchangeable and it's mostly a matter of preference. I use subdomains on message flows and I've seen people who skip subodmains using bouned contexts on core domain charts. So I simply advise people to use which ever terminology they prefer or suits their context for any particular reason. What I find is that the activities and the principles and outcomes are the same regardless of the words. This is just my personal experience based on how I work with clients. Each to their own.

…

On Wed, Jan 3, 2024 at 2:27 PM Kenny Baas-Schwegler < ***@***.***> wrote: Ah we are close to jumping rabbit holes :D.... The problem however IC is that in domain message flow modelling bounded contexts is mentioned and not subdomains. And the litarature out there makes the distinction between the two, which there is. I find it important to teach, but I might not use it during workshops because they have both seperate purposes in my honest opinion. Now I agree that the focus during Collaborative modellings should not be on the dogmatic. And it is all about the concepts of grouping and taking ownership and responsbiliy so we agree there. However problems might not be noticible, but there might be confusion because of the ambiguity when people read this and the litarature. So your proposal of highlighting it would be a good first step. And perhaps then see if we need to go further. — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFI67Q4YOFSJVQ4SE6N3M3YMVTEPAVCNFSM6AAAAABBLIEXRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGQ2TOOJTGY> . You are receiving this because you commented.Message ID: ***@***.***>

[geovanneb]

Firstly, I want to highlight that we have been using this practical approach, introduced by the DDD team, for over a year now, and it has proven very useful!

With that said, I agree with some team members that adding a clear explanation of domains, subdomains, and bounded contexts at the beginning of this guideline would be good.
Consistently using these terms throughout the guideline would also make it easier to follow.

Based on my research, the definition that I liked the most is that "domain" and "subdomain" can be used interchangeably. When we say "subdomain," we are usually highlighting that this domain is a part of a larger, higher-level domain. However, the concept of a "subdomain" isn’t standardized across organizations, and I believe that’s where much of the confusion comes from.
That is the reason why I don’t think "bounded context" and "subdomain" can be used interchangeably.
Unlike subdomains, this "bounded-context" is well-defined in DDD, so it’s something everyone in DDD can understand consistently.

Therefore, I think this DDD approach should focus on "bounded context" which is the clear physical and logical boundary we aim to define with DDD.

Domain, Subdomain: Not standard across organizations, no consensus, therefore cannot compare.
Bounded-Context: Very well defined in DDD