The connection between subdomains and bounded contexts seems lost

[cer]

The previous step discovered subdomains.
How do those subdomains relate to the bounded contexts?

ddd-starter-modelling-process/README.md

Line 307 in dc70a3f

Define the roles and responsibilities of each [bounded context](https://martinfowler.com/bliki/BoundedContext.html).

[skleanthous]

Hey @cer, speaking personally, I've found that the answer varies depending on the organisation and the team driving the design and implementation effort.

One reason is that while the BC is defined as being "the boundary within which domain-specific terms have a cohesive meaning", the subdomain is a bit more abstract in meaning and usually aligns with departments in the business. As an example of the variance I'm mentioning above, I've seen organisations considering "Billing" as a sub-domain, but that encompassed two BC's, one with invoices and another for dealing with actual payments. At the same time, I've seen organisations where a "billing" subdomain aligned with exactly one BC that didn't have conflicting terms simply because it wasn't something core to the business offering.

The answer is made somewhat more complex by the fact that while the BC is defined by conflicts in terminology, there is a clear aspect of design to them (and not discovery), meaning people can actively decide where that boundary sits, and deal with conflicting terms simply by coming up with new terms or redefining the definition of a concept, so there is no conflict within a boundary.

[NTCoding]

There's a 1:1 mapping (bearing in mind there is a current and target state, so current state subdomains and BCs might not align with target state/desired subdomains and BCs).

Subdomain is where you draw the conceptual boundaries whereas BC is more of a principle and technical implementation, i.e. create a unique ontology (aka model and ubiquitous language) and decoupled implementation for each subdomain.

In practice, the two terms can be used interchangeably so it usually comes down to preference or audience. Some people even go straight to BCs and ignore the term subdomain altogether. But in practice that doesn't change the activities or anything tangible (it's just a personal preference).

Whenever you create a BC it needs to be aligned to some domain boundaries. Therefore, you have defined or identified a subdomain whether you use the term or not.

Caveat: you'll probably get lots of other opinions, this is just my point of view and I'm not saying this is better than any other points of view. It's just where I've ended up based on experience over the last 15 years.

[cer]

@NTCoding @skleanthous Sure. But when I read the starter process the actual words don't say that. There needs to be some text gluing the different sections together.

[NTCoding]

@NTCoding @skleanthous Sure. But when I read the starter process the actual words don't say that. There needs to be some text gluing the different sections together.

Could you elaborate on how adding text gluing the sections together would be beneficial? I quite like the current version because it isn't too prescriptive and allows for some flexibility.

I haven't heard this feedback before so keen to understand what the tangible benefits are and in what scenarios it would be useful.

Cheers

[skleanthous]

I feel obligated to add this here: ddd-crew/strategic-architecture-building-blocks#1 as there is quite a bit of relevant discussion in that very long thread.

[skleanthous]

But also, I'd like to add that while my experience is significantly smaller than @NTCoding (to put the following in the right context), I have seen the same thing as Kenny's response here more often (again speaking from small personal experience) which is what I based my initial response on: ddd-crew/strategic-architecture-building-blocks#1 (comment)

My running assumption why this is is that the business domain is something the business is aware of, often aligning with sectors and industry and government categorisations of companies and field they work in. And in those situations the subdomains tend to follow a similar mentality going down, and don't (always) align necessarily to BC's which I agree with @NTCoding are indeed a design-based decision (although I wouldn't necessarily say it's a technical implementation one).

[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