1)
Evan's book, pg. 415:
Also, the critical aspects of the domain model may span multiple Bounded Contexts, but by definition these distinct models can't be structured to show their common focus.
a) I assume the quote is implying that Core Domain CD can span several Bounded Contexts BCs?
b) I assume BCs within CD should only contain core elements, but no generic elements? If so, doesn't that mean we should always design BCs ( those contained by CD ) with Core Domain in mind? In other words, we should have some general idea what CD is even before we begin designing BCs?
c)
... but by definition these distinct models can't be structured to show their common focus
I realize that BCs shouldn't be structured such that outside world would be able to immediately figure out how all the parts ( ie BCs ) fit together and what their common purpose is, but is author implying that such a structure ( which would implicitly convey the common purpose of different BCs ) couldn't happen even by accident? If so, why?
2) Domain Model may have several Generic Subdomains GSs , but can a single GS span multiple BCs?
UPDATE:
1)
b)
I assume BCs within CD should only contain core elements, but no generic elements? ...
One should certainly have an idea of what the core domain is when defining BCs. As stated, ideally, they should be one-one. However, a BC may be defined to fulfill needs of of a system in a non-ideal state.
I assume you're implying that in non-ideal situation BC within CD may also contain some non-core elements and also in non-ideal situation CD may contain more than one BC?
c)
A domain spans multiple BCs but despite explicit boundaries, domain behavior can certainly span BCs. A context map can describe such cross-BC interactions. The quote itself is based around the idea of a domain vision statement the purpose of which is to highlight the value of the core domain and possibly explain the relationship to BCs.
But why is author using the term "by definition", as if to imply there is no way that BCs could accidentally also be structured such that they would show their common focus?
2)
Domain Model may have several Generic Subdomains GSs , but can a single GS span multiple BCs?
Multiple BCs can make use of a single generic sub-domain. I would avoid the term "spans" here because that overemphasizes the importance of the generic sub-domain for the entire domain model.
a)
Multiple BCs can make use of a single generic sub-domain
Not sure I understand your reply. Are you saying that a single GS can contain multiple *BCs*?
b)
I would avoid the term "spans" here because that overemphasizes the importance of the generic sub-domain for the entire domain model.
Perhaps a useless question, but could you elaborate on why using the term "span" would make Generic Subdomain appear more important than it actually is?
REPLYING TO Giacomo Tesio:
1)
b)
No, some generic elements often play a key role in the Core Domain. See for example Time, Currency and Money that are present in many Shared Kernel: they are really generic but important to the Core Domain rules.
So if generic element ( such as Time, Currency and Money ) is also used by Core Domain, then only implementation option is Shared Kernel ( ie this generic element is shared by both Core Domain and any other subdomain(s) that needs it ), but if generic element is used only by Core Domain, then we shouldn't bother with Shared Kernel, but should instead define this generic element directly within Core Domain ?
1)
c) Context boundaries are defined after term's semantics. In a BC, no term should mean more than one thing (see SRP). When you see that a class has more than one meaning in the domain expert's mind, you know that you have mixed differnt BC.
Could you expand on your answer a bit, since I fail to understand how your answer relates to my question?
SECOND UPDATE:
1)
b)
It may also be that a single BC contains multiple sub-domains. This is usually not ideal because it likely indicates a conflated BC.
When reading the book, I haven't pay much attention to author's usage of the term "subdomain", but I'm pretty certain that the book doesn't offer a thorough definition of what a subdomain is. So what exactly is considered a subdomain? Just a bunch of logically related domain concepts? If yes, then I assume a subdomain should never span several BCs?
2)
a)
A signle GS can be used by multiple BCs. This is so because the sub-domain is generic. So the GS doesn't contain the BCs; instead, it is referenced by the BCs.
From your reply it seems you're implying that Generic Subdomains are never implemented as BCs? Why not, since in my opinion different Generic Subdomains may contain distinct models and BCs seem ideal solution to separate those generic models?!
3) Could you also help me with the following question, since it's confusing me quite a bit: if generic element ( such as Time, Currency and Money ) is also used by Core Domain, then only implementation option is Shared Kernel ( ie this generic element is shared by both Core Domain and any other subdomain(s) that needs it ), but if generic element is used only by Core Domain, then we shouldn't bother with Shared Kernel, but should instead define this generic element directly within Core Domain ?
thank you
Anything that shows domain concepts, relationships, rules, and so on. Since a bounded context is a boundary for a model, it could include concepts from multiple subdomains. Or a single subdomain could be modelled as multiple bounded contexts.
The domain represents the problem to solve; the domain model is the model that implements the solution to the problem. Likewise, a subdomain is a segment of the domain, and a bounded context is a segment of the solution.
A bounded context is simply the boundary within a domain where a particular domain model applies. Looking at the previous diagram, we can group functionality according to whether various functions will share a single domain model. Bounded contexts are not necessarily isolated from one another.
1a) In that quote the author is referring to the entire domain, not the core domain. The entire domain can span multiple BCs. The relationship between a BC and core domain can be more complicated. Domains, sub-domains and the core domain are elements of the problem space. A BC is an artifact of the solution space. In reality, they may not always be one-to-one, however that is the ideal.
1b) One should certainly have an idea of what the core domain is when defining BCs. As stated, ideally, they should be one-one. However, a BC may be defined to fulfill needs of of a system in a non-ideal state.
1c) A domain spans multiple BCs but despite explicit boundaries, domain behavior can certainly span BCs. A context map can describe such cross-BC interactions. The quote itself is based around the idea of a domain vision statement the purpose of which is to highlight the value of the core domain and possibly explain the relationship to BCs.
2) Multiple BCs can make use of a single generic sub-domain. I would avoid the term "spans" here because that overemphasizes the importance of the generic sub-domain for the entire domain model.
UPDATE
1b) It may be that a core-domain is implemented with multiple bounded contexts. This isn't necessarily a defect and in some instances is the ideal. It may also be that a single BC contains multiple sub-domains. This is usually not ideal because it likely indicates a conflated BC.
1c) By definition BCs are physically partitioned and shouldn't have direct dependencies. I think this is what the author is referring to. The issue he's highlighting is that you can have multiple BCs at play which warrants explanation, especially when a single sub-domain is addressed.
2a) A signle GS can be used by multiple BCs. This is so because the sub-domain is generic. So the GS doesn't contain the BCs; instead, it is referenced by the BCs.
2b) Having a generic sub-domain "span" the system may be an indication that it isn't really a generic sub-domain, but a core domain. This is not to say that a generic component can't be used throughout the system, quite the contrary. However in that case, the component spanning the system is only a technical axis.
UPDATE 2
1b) Yes a sub-domain is a cohesive component of the entire domain. A sub-domain can span multiple BCs. This can be acceptable because a BC is a solution space artifact and there can be technical reasons or even organizational issues for its existence. For example, in the domain of an online retailer there is a product catalog sub-domain. This would have a corresponding products BC. However, additional functionality regarding product search can be placed into a product search BC. This is still part of the catalog sub-domain, but a new BC for technical reasons. On the other hand, when a single BC contains multiple sub-domains, this can be problematic.
2a) I think I got overly semantic on the use of the word span. A generic sub-domain can be a BC. However, care must be taken to ensure that a generic sub-domain is in fact used in a generic way.
3) Yes. Beyond that, base classes like Money can be implemented uniquely for each sub-domain even if they are used in multiple places. Sometimes copy-and-paste is the best pattern.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With