Azure Function Architecture (HTTP Trigger)

The following describes a proposed simple architecture that can be applied when creating Azure Functions that use HTTP triggers.

Azure Function architecture when using a HTTP trigger.

The application contains three main assemblies: Func, Contract and Core.

• Func assembly’s main responsibility is handling the incoming HTTP request from the Client and returning the outgoing HTTP response.
• Contract assembly defines the application’s contract of use. This is done through defining request and response objects. Contract has no dependencies on either the Func or Core assemblies. The assembly can also be published as a nuget package and made available for use by the Client application (if it is written in .NET).
• Core assembly is the main part of the application and will be where most of the application’s code resides. It contains logic for handling the request: including validating the request and all related business logic such as domain model services and entities.

An incoming request from a potential Client would go through the following steps:

1. A HTTP Trigger class in the Func assembly deserializes the HTTP request to the required Contract request model.
2. The Contract request object is passed to the Processor class in the Core assembly.
3. The Processor validates the request and then handle the request how it sees fit using the business logic domain model objects.
4. After handling the request is complete the Processor would then construct a Contract response model and return it to the HTTP Trigger.
5. The HTTP Trigger then serializes the Contract response model and returns the response to the Client.

The main benefit of using an architecture such as this means the Core assembly has no knowledge of how it is being used. This is essentially a plug-in architecture where the Core application could be easily ported to any other host application type; e.g. web API, console application, windows application etc.

The other main benefit is that all data in and out of the Core application is defined in the Contract. Having this self contained Contract assembly versioned and published to a nuget feed also provides benefits to potential .NET Client applications that wish to call the function app.