Do Core Domain and Generic Subdomains contain different parts of the same domain model?

Question

a) Do Core Domain and Generic Subdomain ( GS ) in most cases contain different parts of the same domain model or does each GS define its own domain model, which is usually different from the model used in Core Domain?

b) If the former, then I assume the reason for both using the same model is because the primary purpose of GS is to "serve" a Core Domain, and GS can "serve" best if there's no need for a translation layer between the Core Domain and GS ( if each used its own model, then we'd also need a translation layer between the GS and Core Domain )?

thanks

Answer 1

Core Domains, Supporting Subdomains and Generic Subdomains evolve around the concept of the Bounded Context in DDD.

To answer your question, the Core Domain is the domain which makes your business unique and gives you an advantage over your competitors - you will put most efforts (developers/monry) into improving it. A Generic Subdomain handles a topic that is still important but there is a chance you'll find an existing solution (either as a concept or reusable code) that handles the tasks good enough.

The Generic Subdomain would have a different model because it tackles a different domain.

A Generic Subdomain may describe anything from date/time(zone) handling see (2, Ch. 15), persistence, the user-interface toolkit up to a mail server or a complete inventory management system (1, Ch. 2). On the other hand, the inventory management logic is the Core Domain of the inventory management system's vendor.

You can find in-depth information in the book Implementing Domain-Driven Design and of course in the original book introducing Domain-Driven Design by Eric Evans.

Update: (see comment)

In my opinion, the most important aspect in Core Domains using any kind of Subdomain is not to overthink this topic on an abstract level. You'll probably agree that the biggest challenge in Domain-Driven Design is to find good examples that, by plan or accidentally, match the patterns/strategies from the Strategic Design section of the Domain-Driven Design book.

Now, from my understanding, the need for a translation layer between Core Domain and Generic Subdomains arises simply from necessity. In Chapter 15, Distillation of Domain-Driven Design four options on how to develop Generic Subdomains are discussed with their corresponding pros and cons:

1. An Off-the-Shelf Solution
2. A Published Design or Model
3. An Outsourced Implementation
4. An In-House Implementation

I won't repeat the discussion because this would just include quoting from the excellent book. You'll probably agree that a custom tailored and well-designed in-house solution, that is only used for this project, does not need a translation layer. On the other hand, a commercial or open-source Off-the-Shelf Solution is more likely to require an abstraction because you have little control on how the product evolves, if it has an appropriate Intention-Revealing Interface and so on.

There are two other aspects that are related but should not be mixed up with Subdomains:

• Communication between Bounded Contexts
• Cohesive Mechanisms

Bounded Contexts need some kind of translation by sheer definition. For each Bounded Context, there is a Model in Context. A Context Map documents the relationships and interactions of Bounded Contexts with Translation Map. The different ways of relating models of BoundedContexts are discussed in Chapter 14, Mainting Model Integrity (Anti-Corruption Layer, Open-Host Service and others).

Cohesive Mechanisms (see Chapter 15 of Domain-Driven Design), on the other hand, are similar to Generic Subdomains as both are introduced to relieve the Core Domain from unnecessary clutter. Eric Evans describes Cohesive Mechanisms as a lightweight framework but admits that in practice the distinction between Cohesive Mechanisms and Generic Subdomains is mostly not pure.

I'd like to say that I had to read those sections again as I do not deal with this on a daily basis so please be forgiving. Additionally, I am not in the inner circle of the DDD community and thus I am not aware if these issues are evaluated differently today. They still seem very useful to me and I have not encountered a better set of tools in this area so I assume they are still valid.

I understand the urge to understand these concepts but a real understanding can only be achieved by looking at concrete examples. Some are mentioned in the books. None of them are claimed perfect. The understanding and assessment of these complex problems, large or small, changes over time and this the soul of DDD in my opinion.