Can Core Domain span multiple Bounded Contexts?

Question

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

Weigh

Answer 1

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.

Coinsurance

I apologize for dragging this topic, but could you see my second update? – Weigh

Answer 2

1a) Yes, the Core Domain essentially is the set of bounded contexts that worth the application's development from the customer point of view.

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

1c) Context boundaries are defined after terms' semantics. In a BC, no term should mean more than one thing (see also SRP). They are almost linguistic boundaries! When you see that a class has more than one meaning in the domain expert's mind, you know that you have mixed different BC.

2) Yes, Generic Subdomains are those part of the domain model (or, the set of the bounded contexts) that are useful but not central in the application. I've built several applications with generic subdomains: when they add some value that the customer wish to pay (and I can't provide such value with a simple CRUD component).

Note that what's "Core Domain" in your application is a qualitative definition: I've seen many times secondary parts of successful applications to achieve importance when the customer's corporate organization changed. Thus, what is Core Domain today might be not tomorrow.

Implausibility

You should use comments to reply to answer. Looks like you are thinking about Core Domain, Subdomains and so on like containers. They are not. Neither are Bounded Contexts (even if they usually map to modules). A class is part of the Core Domain if it contributes to describe the main model, the one that is used to solve the problem that the customer has paid for. Context boundaries are defined by semantics, inside a BC each term has an unambiguous meaning. Thus thinking about what contains what is a bit wrong, if easier to understand. – Implausibility

More often than not, a BC is considered as a semantic unit, since the language it expresses is coherent and unambiguos. Thus, we are used to define which BC are part of the CD (aka are the ones that require more investment in term of time and skills). A Shared Kernel is BC, a set of concepts that have the same meaning from all the point of views that depends on them. You can have different shared kernel between different domains, that usually means that you have different pairs of BC that depend on different Shared Kernels. – Implausibility