In Domain Driven Design, a Bounded Context is an ideal way to express concepts in the domain. “Ideal” in the Platonic sense of “relating to ideas”: the concepts and the way people on the project talk about these ideas is important, not the actual code that’s written.

So a Bounded Context could actually be seen in implementation of a library, a module, or a service or process. But more often than that, the boundaries aren’t technical and thus not enforced in code, but ideal, in the heads of the people on the project.

An example for Bounded Contexts I used for Aggregate Roots: a shopping system can have a context for “making an order”, and a context for “listing existing customer’s orders”. On a technical level, both contexts could either declare their own types for their purposes, or use shared types, or both. So the concept of an “order” can actually mean different things: a “pending order”, i.e. one that’s not yet finished, and a “completed order”. You could implement these concepts as 2 different types, PendingOrder and CompletedOrder, or as 1 type called Order with an attribute that indicates completion.