I can give you another example. Consider you have some ecommerce system. You would have products there, however products will be part of at least two different domains:
- Product catalog, where you keep your product description and all attributes
- Inventory, where you have product stock level
If you have one bounded context for both domains, your solution can quickly become a big ball of mud because you will start cross referencing it. At the end you will not have two domains anymore. Your product inventory will be spoiled with product catalog references and vice versa. As the result of this you will not be able to change one domain without touching another even you fully realize this is not required. Your models become dependant on each other and tightly coupled, and dependant in a bad way - being dependant on implementation.
If you, however, have two bounded context, all changes you do in one domain will not affect the other as soon as you keep your communication channels clear. It will mean you need to have data duplication but this is the least cost to pay for losely coupled component based application. Your domains can talk to each other using domain events. Even if you do not plan to have SOA based application in the beginning you will be able to scale up to that level when you need with relatively low effort since you just change the transport for your domain events, leaving the idea behind it intact.
There is a good skillscast on SkillsMatter, from Eric Evans. He gives an analogy of the old story, when several blind man describe an elephant from their perspective. Since each man can only touch a part of the elephant, they describe it as a "tree", "wall", "snake", "rope". And each of those man is right within their context. Bounded context is where ubiquitous language lives. Outside the context, these terms might have completely different meaning but inside the context, the language is the same across multiple domains. Greg Young strongly suggests to start reading the blue book from chapter 11, since the most important, fundamental concepts are explained there. The focus on tactical patterns in the beginning of the book makes this "DDD-light" approach very common, when people stop reading somewhere around chapter 8 and miss the main things, that is somewhat buried at the second half.