Bounded Context

Sometimes aspects of a domain can have slightly different meanings within different parts of that domain.
When we talk about a radio program this can have different meanings for different people and applications. For one program it means something that a producer makes and that has content like talk and music, in an other part of the organisation it could just mean a file that should be transferred to the right place, yet another part of the organisation sees it as something that should be aired.
Still they are all related.
Of course we could put them all in the same domain, but then people don't understand the software completely. By putting them all in a separate domain, a bounded context, it will become more clear how relations go. This way the people who air the radio program don't have to know that that same radio program has a relationship with a producer.

Another reason to introduce bounded contexts is when the domain is getting to big and to complex. It will pay of to put split the domain in multiple bounded contexts.

But there should be a way to connect these bounded contexts. This can be done in several ways. One way is to write a layer between both domains that convert from one domain to an other.
An other way is to use messages and ask for information. This method I will explain in more detail in the next post when I talk about a new idea for the network monitor system.