If we have a large domain in DDD, such as travel, we would divide it into subdomains and create a limited context for each subdomain.
The subdomains are somewhat independent and interact with each other, but often directly with the outside world. Everyone can provide a transaction consistency.
A solution can consist of several limited contexts without necessarily considering the overall solution as its own limited context. We would not expect transaction consistency over the limited contexts and instead use a compensation (do / undo).
It would take more than several interacting limited contexts to create a hierarchical composition from a larger limited context. We would need ubiquitous language, aggregated roots, a domain model, software, transactions, etc. A top-level context would probably subsume the interaction with the outside world.
I associate the term domain more with the problem space, more with the business domain and the term limited context more with the solution space and the automation that we bring to the improvement of the domain (or to enable the domain).