Missing bounded context distillation #46
Comments
|
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)? |
|
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. |
|
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:
***@***.***>
|
|
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. |
|
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:
***@***.***>
|
|
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. 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. 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. |
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?
The text was updated successfully, but these errors were encountered: