Domains/subdomains belong to the problem space. Bounded contexts are part of solution space, for the problems in subdomains.

In an ideal situation, when we have all requirements or the most important requirements and processes, and we correctly discover the subdomains, most often the problem space covers the solution space, its 1:1 relation:

I think this is good starting point to assume bounded context = subdomain. Then when you delve into solution space you get more information. For example, you can discover that some sale processes relate to individual customer and company.
(rules! the same for individual and company or not)
You can stay with solution bounded context = subdomain, or you could distinguish the bounded contexts:

In some systems the individual and company could be different subdomains – different problem space/processes, but for some reason (drivers) you make this:

Is this, ok? Yes, only if it is your conscious decision.

Business is changing constantly, so domains also. In the solution space we should take into account or in some way predict the future changes.

System który budujemy i nasze bounded contexty nie nadąża za zmianami w organizacji, za zmianami subdomen, dlatego Nie zawsze więc będą relacje 1:1 subdomena:bc. Najważniejsza jest tego świadomość i to żeby dążyć do 1:1.

Widać to pięknie w systemach budowanych w tak zwanym zwinnym podejściu, zwłaszcza w dużych projektach, gdzie od samego początku nie myślimy o projektowaniu, bo mamy na głowie do rozwiązania kwestie techniczne. Na początku mamy zbiór wymagań, i budujemy system. Na początku jakoś to wygląda i działa, nie sprawia wiele problemów. Wraz ze wzrostem liczby wymagań nasz pierwotny system zaczyna zamieniać się w pajęczynę zależności. Z czasem jest tylko gorzej i coraz więcej problemów.

Many existing systems looks like this:

Most often one bounded context covers many domains, because in project we do not distinguish the contexts, thats why we build all-in-one/universal models, that satisfy requirements from many domains. (który rozwiązuje jednym modelem wiele różnych subdomen)

Skąd tak źle zaprojektowane systemy się biorą?
Brak wiedzy dotyczącej istotności/tego jak bardzo ważne są domeny i modele w kontekście,
organizacja ewaluuje, zmienia się, a rozwiązanie/system niestety nie nadąża yak szybko za zmianami organizacji,
spływają nowe wymagania, które przecinają/zmieniają wcześniej odkryte domeny/zdefiniowane bc’y
//to jest właśnie niewłaściwe podejście agile, robimy, a potem się zobaczy