Adrin Amin Salehi

Information & Communications Technology

Adrin Amin Salehi

Software Developer / IT Consultant at vi: sit - Vetter IT solutions Schweiz GmBH

Adrin is a software developer and IT consultant at vi: sit - Vetter IT solutions Schweiz GmbH. There he develops tailor-made software for customers in the industrial sector. His focus here is on .NET, Azure, software testing, and software quality. He has been programming with C # since school. As a tech enthusiast, Adrin also deals with cloud computing, IoT, and AI in addition to his work.

Current sessions

The story of building a Visual Studio Add-On, using DDD and CQRS.

We use DDD and CQRS in every new project.
This came as a no-brainer to us in the team, so we decided to rely on these technologies when developing our new applications.

I want to take you on a journey to experience the joys and perils of using DDD and CQRS in a project with many dependencies on other systems. How will this ubiquitous language help us?
How are we going to deal with the many dependencies?
Will we have to adopt the principles of DDD and CQRS to real-world conditions? Or will we have to throw it all overboard altogether?

I can say one thing already: We will be amazed at where the decisions on DDD and CQRS will lead us. We will have more systems than we expected at the beginning - some complex, some less complex. We will gain important insights that will help us plan future projects much better and avoid risks early on.

In this talk, we will have a look at the architecture of a Real-World project that consists of, among other things, a Visual Studio Add-On, which we tried to implement using the ideas and principles of DDD and CQRS.


Building small and highly scalable REST APIs with .NET 6 and Azure Functions

REST is now around for more than 20 years. It's a critical architectural style in creating a standard communication format between computer systems. Nowadays, it is one of the most used foundations for modern web APIs. ASP.NET Core Web gives us an easy way to write clean and simple REST APIs in .NET. But what if we want to leverage serverless capabilities from the cloud? What if we're going to write a serverless REST API that is highly scalable and easy to deploy?

Here is where Azure Functions come into play. Azure Functions is a serverless offer from Microsoft Azure where you can easily create, build and deploy highly scalable serverless functions.

In this talk, I want to demonstrate how to build a REST API fast and easy with Azure Functions and .NET 6. What are the benefits, and might there be any drawbacks? Are there any stepping stones? And how we can leverage Azure Functions and .NET 6 to create awesome REST APIs.


Verifizieren von Business Rules mit Hilfe einer Testing-API

Automatisierte Tests sind ein integraler Bestandteil der Softwareentwicklung. Produktivcode sollte immer, so gut es geht, mit Code Tests (unit, integration, end-to-end) abgedeckt sein. Aber vor allem bei schwammigen oder unklaren Business-Anforderungen neigen wir zu struktureller Kopplung zwischen Produktivcode und Testcode. Im schlimmsten Fall gibt es für eine Methode im Produktivcode eine entsprechende Testmethode. Auf den ersten Blick scheint dieses Problem harmlos zu sein, da man dadurch eine sehr hohe Testabdeckung erreicht. Doch strukturelle Kopplung erschwert späteres Refactoring enorm.

Eine Testing-API zwischen Produktivcode und Testcode löst diese Kopplung. Basierend auf dem Softwaredesign-Prinzip "don't depend on volatile things" ermöglicht diese API das Verifizieren von Business Rules und entkoppelt unserer Tests von der Applikation. Die Erweiterbarkeit ist weiterhin gewährleistet und sollte sich der Produktivcode hinter der API einmal ändern, laufen unsere Tests immer noch durch.

Die Implementation einer solchen Testing-API ist kein Selbstläufer. Deshalb gilt es folgende Fragen zu beantworten:

- Wie konzipieren wir solch eine API am besten?
- Können wir solch eine API überhaupt in unser bestehendes Software-Design implementieren?
- Wie lässt sich solch eine Testing-API mit .Net aufbauen?


Scrum mit Azure DevOps von 0 auf 100

Am Anfang eines Softwareprojektes gibt es viele Fragen zu klären: Welche Architektur nutzen wir? Wie sieht das Software-Design aus? Welchen Tech-Stack wollen nutzen wir? Wenn man diese Fragen geklärt hat, will das Team meistens direkt mit der Entwicklung beginnen. Doch dann stellen sich noch weitere, größere Fragen.

Mit welcher Methodik wollen wir arbeiten und mit welchen Tools wollen wir unsere Prozesse abbilden???

Diese zwei Fragen sind genauso wichtig wie die vorherigen, wenn nicht sogar noch wichtiger. Denn ohne klar definierte Prozesse und Tools, stehen sich,insbesondere bei größeren Teams, die Teammitglieder oft gegenseitig im Weg. Dennoch wird recht voreilig auf Scrum oder Kanban als agile Methodik zurückgegriffen. Aber hier fehlt leider immer wieder das effiziente Zusammenspiel von Tools und Prozessen.

Azure DevOps bietet viele Möglichkeiten, um Teams innerhalb des agilen Prozesses zu unterstützen. Egal, ob Item-Tracking oder Kapazitätsplanung. Es gibt viele Einstellungsmöglichkeiten, um agile Prozesse sauber abzubilden.

Anhand der Erfahrung aus verschiedene Projekten stelle ich praktische Best Practices zum optimalen Einsatz von Azure DevOps im Scrum Prozess vor. Auf was muss geachtet werden, um beide Welten zusammenzuführen? Und was sind Stolpersteine, auf die man gerade am Anfang der Projektphase achten sollte?