I am considering how to set precise boundaries of bounded contexts. Considering that a bounded context is a solution space, sometimes it is very difficult to set what exactly is your solution space.

Here is an example.
I have following bounded contexts

• Ordering
• Messaging
• Content management
• Warehouse etc.

So in a real life situation this is a possible situation

• Ordering needs to send a notification
• Ordering gets a message draft from Content management
• Ordering formats a message and forwards it to Messaging
• Messaging send a notification and does all the work relevant for that BC (send message, archives it, logs it etc)

This looks like a valid design, but I have some doubts regarding it.
For example, should Messaging be also part of an Ordering “solution space” and also maybe Warehouse “solution space” (not as BC of-course, just as code). In that case design of Messaging could change for each “solution space” according to its needs (if any).

By pulling it out from multiple BCs I wanted for Messaging to be a part of Messaging “solution space” (to solve requirements of messaging process), so a different BC can use it (anti-corruption layer) without duplicating its logic into multiple BC.

Both scenarios are valid, first scenario tends to have other BCs depend on Messaging BC without duplicate code, and other scenario offers full autonomoty to each BC, no Messaging BC, “duplicate” code and probably higher usage of resources in that BC.

So could be a good way to define boundaries of a problem/solution space? Should it be based on certain DDD guidelines, limits of hardware resources, or something else?