Building a Boardgame in Azure

It’s all about friendships

This board game is played with a fixed amount of 4 players. And since I’m pro-privacy, I don’t want random people to be able to play with each other. You have to have some sort of connection or at least agreed upon playing together. This is why I want the system to contain friendships. For each user in the system, I will generate a Friendship ID which is a ten-digit, easy to communicate number to share with your friends. Other users can use this number to request a friendship. Friendship requests will show up in a list and users can accept or decline a friendship request. When a user creates a new game, a select box is shown with friends who accepted the friendship, so this user can choose three to play with.

The approach

I’m not really a supporter of the microservices architecture when starting the development of a new software system. In my opinion, you should really identify boundaries and make sure there are built-in in your software system so that you can easily isolate services when needed. But the full-blown microservices architecture requires a lot of plumbing at the cost of development (delivery) speed. I think the friendships functionality is a nice domain, so I’ll create models, a service, and a repository to handle everything we need to drive the friendships stuff. While making as little references to other services as possible.

Event-driven architecture

For some reason, I think an Even Driven architecture is a nice way to solve the friendships problem, but I’m not sure if it’s a bit of an overkill to do so. Let’s just give it a try and see where I end up with… Architecture Friendships

The idea is to use the same approach for both sending a friendship request, and accepting or declining a request. The user sends a request using the user interface, sends an HTTP Request to an API which validates the request and then sends a message to a Service Bus Topic. This topic has two subscriptions. Both subscriptions forward the message to a queue and two Azure Functions, triggered by the queues, will handle the messages.

Function A

Will handle the message and store changes in persistence (in this case probably a SQL Server Database).

Function B

Will send a message through SignalR to the appropriate user notifying a friendship request arrived, or a request has been accepted/declined.

Regrets…

Friendships - Invitation So I have developed the Friendships part, created a nice user interface and all… But I’m not really satisfied… In the end, the Event-Driven part was a way of an overkill. I built the Topic with subscriptions to queues, all for eventual consistency, but this is really not a requirement here. The message sent using SignalR can be interpreted as an event and is not really a message, or command if you like. I built a nice domain model representing a friendship, all validations are done using that domain model, I’m pretty satisfied with that. But once the validation is done, I don’t do anything more than creating a new message and dumped that message on a Topic. It really makes more sense to apply changes to the domain model and send those changes to a repository to persist the changes.

Planned refactory

I’m definitely going to refactor this code to do exactly that. Make sure the service drives the domain model and then persists all changes in the domain model. And while making changes to the domain model, raise events that are sent to the Service Bus (or Event Grid). The Azure Function sending notification messages to users can remain.

Last modified on 2020-07-01