Core Domains , Supported Subdomains , and Common Subdomains are evolving around the concept of Limited Context in DDD.
To answer your question, the Main domain is a domain that makes your business unique and gives you an advantage over competitors - you will put more effort (developers / monologues) to improve it. A Common subdomain handles a topic that is still important, but there is a chance that you will find an existing solution (either as a concept or reusable code) that does a good job of it.
The common subdomain will have a different model because it resolves a different domain.
A Common subdomain can describe anything with date / time (zone) processing, see ( 2 , chapter 15), persistence, user interface toolkits to the mail server or a complete inventory management system ( 1 , chapter 2). On the other hand, the logic of inventory management is the main domain of the supplier of the inventory management system.
You can find detailed information in the book Domain-Driven Deployment and, of course, in the original book representing the Project, developed by Eric Evans .
Update: (see comment)
In my opinion, the most important aspect in the Primary domains using any Subdomain is not overworking this topic at an abstract level. You will probably agree that the biggest problem in domain-based development is finding good examples that, by plan or by chance, match the patterns / strategies from the Strategic Design section of the Domain-Driven Design book .
Now, from my point of view, the need for a translation layer between the Main domain and the General subdomains arises simply out of necessity. Chapter 15, “ Domain Management Distillation ,” discusses four options for developing common subdomains with their respective pros and cons:
- Offshore solution
- Published design or model.
- Outsourcing Implementation
- Internal implementation
I will not repeat the discussion because it will just include a quote from a great book. You will probably agree that an individual and well-developed internal solution that is used only for this project does not need a translation layer. On the other hand, a commercial open source solution that goes beyond the shelf is likely to require abstraction because you have little control over how the product develops if it has the appropriate Intention-Revealing Interface , etc.
There are two other aspects that are related to each other, but should not be mixed with subdomains:
- Relationship between Limited Contexts
- Cohesion mechanisms
Limited contexts need some kind of translation by pure definition. For each limited context, there is a Model in context . The Context Map documents the relationships and interactions of Limited Contexts with the Translation Map . Various ways to map BoundedContexts models are discussed in Chapter 14, Model Integrity ( Anti- Corruption Level , Open-Host Service ) and others).
Coupling mechanisms (see Chapter 15 of Domain-Driven Design ), on the other hand, are similar to common subdomains , as both are introduced to reset the primary domain from unnecessary clutter. Eric Evans describes the linkage mechanism as light weight, but admits that in practice the distinction between Cohesive Mechanisms and General subdomains is basically not pure. p>
I would like to say that I had to read these sections again, since I do not do this daily, so please goodbye. Also, I am not in the inner circle of the DDD community, and therefore I do not know if these issues are assessed differently. They still seem to be very useful to me, and I have not seen a better set of tools in this area, so I assume that they are still valid.
I understand the desire to understand these concepts, but real understanding can only be achieved by looking for specific examples. Some of them are mentioned in books. None of them are considered perfect. Understanding and evaluating these complex problems, large or small, change over time, and this, in my opinion, is the soul of DDD.