An Azure service that provides an event-driven serverless compute platform.
One way to approach this would be to use one Function app for each context. Inside the app would be all the functions related to that context. The downside of that is that if you have quite a few different contexts and only a few functions in each then managing it can be unnecessarily unwieldy. In that case I might include two or more contexts in a given app with the intention of splitting them out later if needed.
Using message brokers like Service Bus or Storage queues is a common pattern for passing events between functions, as is functions calling each other directly via HTTP. Which of those you use depends on your specific use case. If you use API Management as your gateway, then it is already setup to handle routing events to multiple function apps while presenting a unified API externally.
For another viewpoint, you may want to take a look at this Build 2020 talk on Event-Driven patterns in Functions: https://channel9.msdn.com/Events/Build/2020/BOD124