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 distinc

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.

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.