To be honest, your question is not easy to understand.
When you start your DDD journey, you identify your domains and bounded contexts. Ideally you have one bounded context per domain but it depends. Each domain has its own domain model, you mention this yourself. But these domain models have nothing in common. They don't know about each other. Your idea to have one base class for two entities from different domains does not fit to DDD. Real domain models do not allow accessing anything within the domain model to anything outside of the bounded context. All communication between bounded contexts go via pre-defined interfaces like queries and commands if you do CQRS. This way you can make your components loosely coupled and allow different groups to work on different domains without depending on each other.
Bounded context always mean separate application. You can think of a separate solution though. It will include a domain project with entities, VOs, commands. It will also include services project with command handlers and query handlers. It will include transport projects like an application that uses service bus for commands and events.
Remember that using domainevents is crucial to enable inversion of control on the business logic level, when one domain informs everyone else about things that happen, allowing the, to react accordingly and do necessary activities. You can think of order payment event in sales domain that triggers a dispatching process in the inventory domain. Sales domain does not even need to know about the inventory domain.
Disclaimer: I'm not a DDD expert, but I'm going to do my best here to answer your questions.
Let's use an Online Book Retailer as an example. A book seller is offering to sell books on his website, but he doesn't print the books himself. Instead, he has a long list of "Book Suppliers" who print and ship the books to his warehouse, were he packages them and ships them to the customers all around the world.
Could you imagine the teams working in that company?
- The listing team: The team that selects which books they should list on the Website, depending on the stock of the suppliers.
- The fulfillment team: responsible for collecting the orders from the Website and managing the orders' life cycle.
- The commercial team: these are the guys who handle adding or removing suppliers from the system.
- The marketing team: responsible for the campaigns and offers.
- The warehouse team: responsible for collecting books from the suppliers and shipping them.
Each team will use its own terms to describe what it is doing. Teams will use the domain language or the "Ubiquitous Language", as Eric Evans calls it. Normally, each team will have a different mental model of what an entity is. For example:
Listing team: BOOK(book_id, ISBN, title, price, weight, length, width )
Fulfillment team: BOOK(book_id, totalPrice, sold_quantity)
Shipping team: ITEM(book_id, delivery_date) --> they refer to the book entity as "item"
A sub-domain is one particular part of the domain, in which some users use a certain Ubiquitous Language. When the language changes, this is an indication the you are crossing into another sub-domain.
What if two teams use the same terms? Both the fulfillment and listing teams call book "book". You will have to ask them, "what is a book for you? What are its key attributes? How is it used?"
Answers to these question will result in two different or similar domain models. The greater the difference between the two models, the more indication that these are two different Bounded Contexts/sub-domains. The opposite is also true. The more similar the two models are, the more likely that they should be part of the same sub-domain.
This may result in very interesting findings in your model. You may discover that inside the fulfillment sub-domain, the orders pass through different states (new -> requested -> shipped). Maybe each of these states requires complex management and different attributes, so you may divide this sub-domain into several other sub-domains.
This brings out a question of what the size of the sub-domain(s) should be. The answer is "let the domain model decide that". Whenever you see a change in the UL and model, then draw a boundary for that sub-domain.
Remember that DDD is all about the business, the people and the communication(s) between them. Let that drive your model.
Best Answer
Bounded Contexts and Subdomains exist at different levels.
A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organisation. So logistics and operations might be separated from invoicing & billing. Eric differentiates core, supporting and generic subdomains according to their business relevance in the given scenario.
Contexts are portions of the solutions space. They're models. It would be a good thing to have them, reflect the domains-subdomains partitioning ...but life isn't always that easy. And you might have bloated legacy domain encompassing everything, or more context in the same subdomain (i.e. old legacy app the replacement app somebody is building).
To have a Bounded Context you need to have a model, and an explicit boundary around it. Exactly what's missing in many data-driven application that use databases to share data.
Another - orthogonal - way to see it may be the following. Ubiquitous Language, the special condition where every term has a single unambiguous definition, doesn't scale. The more you enlarge it, the more ambiguity creeps in. If you want to achieve precise, unambiguous models, you need to make their boundaries explicit, and speak many little Ubiquitous Languages, each one within a single Bounded Context, with a well defined purpose.