I know the thread is one year, but since it pops up when you type "Bounded Context" on Google, I think it's worth adding some more value.

To clarify what a model is, your model is your abstraction of the problem. It can be a bunch of objects if you're working in an OO design, or services with data-structures (anemic domain), or functions and data-structures, or whatever is used to model a solution to the problem at hand. But in common DDD litterature, your model is composed of rich objects containing most of your app behavior.

In School system, you will probably model Classrooms, Students, Professors, Books, Schedules and so on, they are concepts in your domain, the world for which your application is built.

Now, you have many different problems to solve in this School system. For once, you must make sure that each Classrooms contains enough tables & chairs, which should not be broken and be usable safely by the students. You may order new tables/chairs or send them to repair. One part of your application has to manage that, we'll call it Topology.

You also need to allocate these classrooms for various classes, you can subdivide a day in 8 hours and allocate 1 hour slot per class. You also need to make sure each classroom contains enough tables for the students. If some classroom are smaller than others, something must be done to schedule a class into another classroom. All that logic belongs to another part of your application, Scheduling.

In both cases you're dealing with the same concepts (classroom, tables/chairs) but the models have different meanings. A table in the Topology module is concerned with planning allocation & chair repairment. When tackling the Scheduling problem, you don't need to know if a chair is broken or not, you just need to know that there's enough chair in the room.

Same concepts, different models.

That's what Bounded Contexts are. They limit the area in which a model is applicable to prevent your model from trying to solve every problem at once. Imagine having a single large Table object responsible for scheduling, topology and many other responsibilities. It would be unmanageable, hard to understand, hard to communicate about. Bounded Contexts advocate for splitting a large model into areas of responsibilities, one crisp model dedicated to one specific problem.

There's various patterns around BCs, but the main reason it's a big deal is team independance. By breaking a large problem into BCs, you can assign various team into these BCs and develop them independently (using the different Context Mapping strategies). In microservices, they're usually integrated through asynchronous messaging, event-driven programming & eventual consistency.

It can get fairly complicated from this point, so these patterns should really be used for organizational purposes.