This is a proof-of-concept for a full-stack event-based architecture. Everything from the UI to the persistence layer, and from low-level transport to business logic, works with normalized events.
This is also partially an exploration of how to develop, deploy, and manage a serverless web application, and as such is significantly more complex than justified by the scope.
The scope of this POC is extremely limited - creating and saving Person instances.
- An active Azure subscription (you can get a free account if you don't have one).
- The Azure functions tools for Visual Studio - see this article.
Clone the repository, open the solution in Visual studio, and run the Gateway project. The gateway is set up to use RX channels and the CosmosDB emulator locally, so there are no cloud dependencies. The best way to interact with the gateway is to run the web app.
The solution is designed to run both as an in-process monolith and as a distributed cloud app with as little code overhead as possible:
- The Context solution folder has a separate project for the business logic of each bounded context:
- These cover the domain, application, and framework layers
- These are supporting libraries and are not deployable
- They depend only on the Shared project
- The Gateway project:
- Primarily acts as an http-to-channel adapter
- Also includes components which bridge the channels and business logic - these are needed if running as a monolith
- The gateway project also includes ARM templates for the key vault, cosmos db, event grid, and web app
- The Cloud solution folder has a separate project for the Azure functions for each bounded context:
- These functions bridge the channels and business logic, performing the same role as the components in the monolith
- They depend only on the Context project of their bounded context
- The ARM templates for the function web apps are stored here
- The Shared project includes core classes that are used across the other projects
- There are separate Test projects where needed
While this level of complexity is overkill for the very limited scope, this structure and deployment should scale to much larger applications.
Run all the tests in the solution - the tests are written with MSTest and should be recognized automatically by Visual Studio.
The application is set up to run on event grid and functions on Azure. The cloud deployment uses five resource groups, to separate out different resource life cycles - the buttons deploy the dev environment:
- One for the Key vault
- One for the CosmosDB
- One for the Event grid
- One for the Gateway web app
- One for the Azure functions for each bounded context
The event grid and functions resources are not needed if running as an in-process monolith. There are some dependencies between resources which need to be set in the key vault after the database and event grid are deployed:
- cosmosDBAccountEndpoint
- cosmosDBAccountKey
- eventGridPersonProfileContextDecisionTopicKey
- eventGridPersonProfileContextDecisionTopicUrl
- eventGridPersonProfileContextPerceptionTopicKey
- eventGridPersonProfileContextPerceptionTopicUrl
After deploying, publish the Gateway and PersonProfileCloud projects to their app services.
Expanded from Microsoft's best practices.
solution-rg-context?-aggregate?-description?-environment-resource
Were rg = resource group
- eventualitypoc-gateway-dev-rg (gateway dev resource group)
- eventualitypoc-gateway-dev-wa (gateway dev web app)
- eventualitypoc-eventgrid-ppc-perception-dev-egt (dev event grid person profile context perception topic)
- eventualitypoc-cloud-ppc-person-dev-func (dev person profile context person azure function)
- Exception - eventualitypoc-dev-kv (dev keyvault) (24 character limit for key vault name)
This is a proof-of-concept only and will not be developed further.
This project is licensed under the MIT License - see the LICENSE file for details.