This project proved to be a great challenge in trying to be coherent through time with all the notions from the course.
Keeping a clean developement process during the timespan of the project was quite hard partially due to both the use of the Azure Cloud, which was new for basically all the team members, and the fragmentation in time dedicated to the project caused by other personal and academic obligations that didn't allow to have a smooth route from start to finish.
Even so, the team agrees that it was a good way to see in practice the strenghts and challenges of the techniques studied during the course in a "real world" scenario.
Concerning the Domain Driven Design the team started with a long planning session to try to pin down all the concepts and have a clear holistic view of the whole system.
Then after studying the technology chosen to implement the system itself some clashes emerged and it was a bit harder to constantly update the documentation to match in real-time what was happening with the software.
This was identified as the most challenging aspect of the DDD, whilst the analysis process carried out with the tools and the philosophy transmitted during the course felt quite natural and effective since the beginning.
In retrospective the team feels that some cleaner and more coherent with the Ubiquitous Language code could have been created, but, while developing, that felt unnecessary and overcomplex for smaller pieces of software like the Azure Functions and instead was useful for bigger artifacts like the services and the scooter-emulator.
From a DevOps perspective the team put a lot of effort in the automatization of the quality assurance and the deployment of the whole system. This really helped in having a clean, self updating system especially since the final product was a cloud service.
Testing was a bit left behind primarily for time management reasons and because most of the testing was done while integrating different software components instead of having complex business logic that needed intensive single unit tests.
Overall setting up a pipeline from the very beginning resulted in a helpful tool that guided each team member during the development of the system.