Foody’s Architecture

Until the last sprint, we set the rails for our microservices’ architecture. For all the ASP.NET Core backends we make use of Domain Driven Development. Without going too much into details, here is a basic gist of our architecture:

• Domain models are persisted and may consist of a root aggregate, value objects (immutable child of root aggregates) and a repository interface. Actual repository implementations are added by Dependency Injection.
• CQRS – Command Query Responsibility Segregation. Commands fire away data, queries retrieve data. Neither one can do both at the same time. It makes use of the Mediator Pattern.
• Mapping. We use AutoMapper to map from Data Transfer Objects to Commands over to Domain Models, and vice-versa.

Something along the lines MVC

Our setup is an abstraction of MVC. We have Models (our domain models), we have Views (JSON) and we have Controllers. Our controller has a lot more stuff behind it. This code map should serve as an overview:

A quick TL;DR:

ASP.NET Core controllers may contain multiple routes (such as /auth/connect/ and /auth/finalize/). These routes fire a command through a mediator that fetches the associated handler. A command is a POCO (Plain Old C# Class) with read-only properties only.

The mediator looks for the associated command handler that matches the command and executes it. After execution, it returns the result back to the controller and from there back to the view as JSON.

If you’re a nerd like us and you’re curious, take a look at one of the controllers, commands, command handlers and requests handlers (requests consolidate commands and queries for the controller methods).

Tell me why?

This setup makes it fairly easy to separate concerns and maintain business logic without destroying other parts of our code. It also helps to reduce redundancy and improves portability.

Test Driven Development for Backend

I really wanted to try out TDD for the backend projects. Since we would like to include automated tests where applicable, it made sense to create tests for business-oriented classes and test them right away.

.NET Core offers several test environments. One of the popular ones is xUnit. Without going too deep – if you want to read more about TDD, I recommend you to check out this article for more details. The great part of automated testing is that we can easily integrate it with Azure DevOps as part of our CI pipeline:

xUnit allows us to test multiple implementations for interfaces. For example, when we implemented the database repository interface, we implemented the in-memory class first, tested it, and then implemented it as MongoDB implementation, and associated some integration tests to it. It works like a charm.

Frontend Story Time

Isabell and Imke have worked on the client app. Both of them looked further into Angular and Ionic, and successfully connected the canteen pages to the backend.

In addition to that, they’ve tried out several layouts for the start and betting pages. Here’s a screenshot of the non-final static bets page on both Android and iOS:

This should hopefully cover this week’s post. If you have further questions or comments, please let us know in the comments.

Cheers,
Gino