What actually is a subdomain in domain-driven design?

You don't have subdomains inside bounded contexts. It is more like this:

The domain represents the problem space and bounded contexts represent the solution space. In Software terms that would relate an implementation of a solution for a specific problem.

Each company has an overall domain which usually consists of different sub-domains if the domain has a certain complexity (the reason for choosing DDD after all).

It is important to note that these sub-domains can be categorized into:

• core sub-domains, those where the company money makes with their competitive edge)
• supportive sub-domains, things that do not really add value for the end customer but are needed to realize the workings of the core sub-domains, also they represent rather custom problems of the company which cannot be fulfilled with ready implementations on the market and
• generic sub-domains, problems that are very common to several companies

For instance, a flower online shop would have the super fast delivery of flowers at the same day as it's core sub-domain. Then, for instance, their purchasing could be a supportive sub-domain - not relevant to the end customer but complex enough that the problems of that sub-domain are not similar to other companies. And how they secure their website authorization for customers (e.g. using OpenID Connect) would be a generic sub-domain for which they would rather use a ready solution and they would not implement their own identity provider.

The respective bounded contexts are just the corresponding solutions to those problems (sub-domains). Altough there can be a 1:1 mapping between sub-domains and bounded contexts that does not have to be. While sub-domains are discovered bounded contexts are designed and modelled to provide the best solution to the problem space and to define the respective boundaries that make sense in your system.

As developers we cannot choose which sub-domains there are, that's a given. But we can, with respect to the context and constraints of the situation, choose how we cut boundaries, for instance, to have physical separation or also team development responsibility separation. Either way we need to know that a bounded context defines language boundaries and we have to make sure that there is no conflict in the language inside that bounded context.

Update:

I want to answer to the additional question (see comment):

can a bounded context live in more than 1 subdomain. As you can see in the second picture, the bounded context inside of generic subdomain seems to overlap with other subdomain.

I recommend having a look at figure 2.4 and respective text in the book, in chaper 2, REAL-WORLD DOMAINS AND SUBDOMAINS.

In this case the generic sub-domain is ERP (enterprise resource planning). It's a good example for something that is available as software from third party providers and can be integrated into your system.

The respective bounded context ERP is overlapping the inventory and purchasing sub-domains as this implementation also provides inventory and purchasing ERP modules (or APIs) that allow those sub-domains to consume the ERP context.

So although these specific modules (or APIs) address the needs of the supportive sub-domains inventory and purchasing they are implemented in the ERP bounded context rather then the inventory and purchasing bounded contexts.

So yes, although a 1:1 mapping between sub-domains and bounded contexts would be desirable, when it comes to the implementation it can sometimes be necessary that one bounded context deals with requirements from more than one sub-domain. Also, in legacy systems there are often constraints that don't allow you to freely create the optimal design of bounded contexts.

There is a good article about bounded contexts and subdomains.

It says that:

Subdomains and bounded contexts go hand in hand and I think one can’t be understood without the other. The optimal solution would be to have one bounded context in one subdomain. The world is not a perfect place, software even less so, so it might happen that one bounded context spans multiple subdomains, or that one subdomain has multiple bounded contexts.

and author paraphrased words of Vaughn Vernon about subdomains and bounded contexts:

“the subdomains live in the problem space and the bounded contexts in the solution space”.

and then author gives good example:

When writing software that will support the business and help solving the problems coming from the core domain and supporting subdomains we create models. These models will be “fine tuned” so that they provide the most optimal solution for the problem. But to provide these solutions, we also need to say what is the context of these models in which they help solve the problem.

Imagine a software that is being developed to support a dentist. A dentist has two problems: fixing patients’ teeth and making appointments for the patients. Fixing teeth is the core domain and making appointments is a supporting subdomain. In the core domain the medical staff cares about a patient’s dental history, can they handle general anesthesia or not, what their current problem is, etc. In the subdomain the staff (not necessarily medical staff) cares about a patient’s contact information, a date and a time that best suits both the doctor and the patient, the type of dental work needed, etc. Both domains need a model of a patient, but that model will depend on the bounded context we put in place to ensure the correct information and features are available when solving the problems of each domain.