ddd-crew / ddd-starter-modelling-process

If you're new to DDD and not sure where to start, this process will guide you step-by-step
Creative Commons Attribution Share Alike 4.0 International
4.64k stars 426 forks source link

The connection between subdomains and bounded contexts seems lost #61

Open cer opened 3 months ago

cer commented 3 months ago

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

https://github.com/ddd-crew/ddd-starter-modelling-process/blob/dc70a3f35d86246af4e712a06bfd521f486856d6/README.md?plain=1#L307

skleanthous commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

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

skleanthous commented 3 months ago

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: https://github.com/ddd-crew/strategic-architecture-building-blocks/pull/1#issuecomment-731012074

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).