Previously on...

I finished up my previous series about how I started to explore the consultant side of the IT sector.

This blog post starts a new series. Below you can find a bullet list of what is used in this project. The topics on which I'll be blogging are DevOps, Analyses, Development, Acceptance Environments, Documentation and Knowledge sharing. This way, I have some structure on what I can write about next.

Through this, I want to inspire others or have discussions about why other approaches can be more beneficial.

Context

I help deliver a project that will enable a user to signup into the customer portal using a registration system. The customer asked me to develop two Web App services that are functioning as REST APIs.

When a user signs up, he will have two options:

• using Auth0 and ItsMe, so the user can be verified using the ItsMe app

• using personal data with verification sent by sms or email.

Technology used

DevOps

I do not have access to create pipelines and resources in Azure DevOps. However, I do function as a lead for my services so I do work closely with the DevOps persons when problems arise or information is needed.

• All services make use of continuous integration as well as continuous development. The customer describes what branching strategy I should use.

• The entire solution is deployed using Web App ASE on Azure.

Analysis

This has already been done by the enterprise architect and the business analyst. What I did was help with:

• Clarifications and documents to reflect what is development

• Challenging content of access tokens

• Challenging REST-call signatures

Development

The setup of the solution consists of a service-oriented architecture. With some good faith, you can see some resemblance with the microservice-oriented architecture.

• Backend services make use of Asp.net core version 6.0 using swagger as documentation.

• The user interface makes use of Asp.net core MVC 6 and swagger.

• The services can only talk to each other when using Azure API Management.

• Secrets should be handled with care using Azure Key vault. For local development, secrets are not checked in the repository.

• All consumers should identify themself using Oauth2. Claims are used for authorization. For some legacy services, certificates are used for authorization.

• I use validation using FluentValidation. An extension for integrating FluentValidation with Swagger is used. Attributes are used as less as possible to have clean data transfer objects.

• In the core of the REST services, a domain is created. However, I would not call this domain driven design.

• Separation of concern ( and layers ) is enforced using the use of mappers.

• The package Polly is used when libraries do not retry on Http Status Code 429.

• Exceptions are there when unexpected technical behaviour occurs. I made use of CSharpFunctionalExtensions nuget-package to have support for validation during the whole flow.

• Configuration happens using appsettings.json and using the IOptionsMonitor. AzureKeyvault extensions are enabled.

• Classes are marked as internal and sealed where possible for performance gaining.

• Newtonsoft.json is used as less as possible. The one that should be used the most is System.Text.Json

• Dependency Injection is used

• Logging is enabled using the native Application Insights library package. For local logging, The NuGet package NLog is used with Microsoft Extensions.

Acceptance Environments

The business analyst will validate the services using SoapUI and PostMan. Whenever an error occurs, extra system tests and/or unit tests are written.

Documentation

The analysis needs to reflect what is going to be developed, as well as what is developed. However, I make it my mission to put as much of the documentation in swagger.

Knowledge sharing

• Each week, there is one hour that the .Net developers on the project meet to exchange strange issues, nice discoveries and so on.

• Using the 4 eyes principle, we can help out each other.

• When there is some discussion where the customer does want to have some answer, I do talk to my XPirit colleagues about it. After having the discussion, I write a concise email to the customer with the problem and how we recommend approaching this.

Outro

With this post, I have mentioned a lot of technologies, architectures, and ways of working that I will explain more about in the next posts. Let me know what topic you want to know more off in this context.