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.
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.
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.
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
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.
The services can only talk to each other when using Azure API Management.
All consumers should identify themself using Oauth2. Claims are used for authorization. For some legacy services, certificates are used for authorization.
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.
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
The business analyst will validate the services using SoapUI and PostMan. Whenever an error occurs, extra system tests and/or unit tests are written.
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.
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.
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.
Did you find this article valuable?
Support Kristof Riebbels by becoming a sponsor. Any amount is appreciated!