This is a solution which uses the Clean Architecture templates to demonstrate how to integrate with Azure Functions using .NET 5. This is work in progress as the Azure Functions Worker is in preview.
- Azure Functions Worker
- Entity Framework Core 5
- MediatR
- AutoMapper
- FluentValidation
- NUnit, FluentAssertions, Moq & Respawn
- Docker
- Install the latest .NET 5 SDK
- Install the latest Azure Function Core Tools
- Open the solution in Visual Studio or Visual Studio Code (Preferred)
- Press F5 and the function app should start
- For Visual Studio Code, Locate FunctionApp/TodosTesting.http file and execute API calls with REST Client extension
Check out Jason Taylor's blog post for more information on getting started with clean architecture and using the original template.
TBA
The template is configured to use an in-memory database by default. This ensures that all users will be able to run the solution without needing to set up additional infrastructure (e.g. SQL Server).
If you would like to use SQL Server, you will need to update FunctionApp/appsettings.json as follows:
"UseInMemoryDatabase": false,Verify that the DefaultConnection connection string within appsettings.json points to a valid SQL Server instance.
When you run the application the database will be automatically created (if necessary) and the latest migrations will be applied.
To use dotnet-ef for your migrations please add the following flags to your command (values assume you are executing from repository root)
--project src/Infrastructure(optional if in this folder)--startup-project src/FunctionApp--output-dir Persistence/Migrations
For example, to add a new migration from the root folder:
dotnet ef migrations add "SampleMigration" --project src\Infrastructure --startup-project src\FunctionApp --output-dir Persistence\Migrations
This will contain all entities, enums, exceptions, interfaces, types and logic specific to the domain layer.
This layer contains all application logic. It is dependent on the domain layer, but has no dependencies on any other layer or project. This layer defines interfaces that are implemented by outside layers. For example, if the application need to access a notification service, a new interface would be added to application and an implementation would be created within infrastructure.
This layer contains classes for accessing external resources such as file systems, web services, smtp, and so on. These classes should be based on interfaces defined within the application layer.
This layer is the entrance to the application and utilises the Azure Functions runtime. This layer is designed to be thin veneer within minimal logic and no application concerns. It depends on both the Application and Infrastructure layers, however, the dependency on Infrastructure is only to support dependency injection. Therefore only Startup.cs should reference Infrastructure.
If you are having problems, please let us know by raising a new issue.
This project is licensed with the MIT license.