Zum Auftakt unserer Server-Woche mit Workshops zu Architekturen mit
- Spring Boot,
- ASP.NET,
- NestJS und
- API Security
haben wir mit Kai Tödter von der Siemens AG über seine Erfahrungen zu Micro Services, DDD und REST APIs gesprochen.
Kai Tödter ist Principal Key Expert für Softwarearchitektur und -technologien bei Siemens Smart Infrastructure. Er hat mehr als zwanzig Jahre Java-Erfahrung und vertrat Siemens im Java Community Process (JCP) und in der Eclipse Foundation. Kai ist Committer bei einigen Open-Source-Projekten, seine aktuellen Themenschwerpunkte sind Technologien im Webumfeld, Microservices und Hypermedia-APIs.
Spoiler: Kai ist auch Trainer für Spring Boot im Rahmen unserer Server-Woche.
Kai, Du und Dein Team bei der Siemens in München setzen ja schon länger auf DDD. Was sind denn Deine Learnings aus all diesen Jahren?
Es ist sehr wichtig, das Business und Development mit der gleichen Sprache über die Domain sprechen (Ubiquitous Language). Weiterhin helfen gemeinsame Workshops (Domain Storytelling, Event Storming) sehr, dass alle Beteiligen die gleiche Sicht auf die Domain haben. Weiterhin hat sich gezeigt, dass Entwickler es sehr zu schätzen wissen, wenn sie Technologie-Stacks wie z.B. Spring benutzen können, die sowohl strategisches wie auch taktisches Design unterstützen.
Wie verwendet Ihr DDD im Frontend und habt Ihr dort den selben Domänen-Schnitt wie im Backend?
Kommt ganz drauf an. Wenn wir Self-Contained-Systems bauen schon. Manchmal aggregieren wir allerdings auch mehrere bounded Contexts innerhalb eines Frontends.
Du bist auch seit Jahren ein bekennender Befürworter von REST. Wie passt das Ressourcen-orientierte REST mit DDD zusammen?
Wenn man RESTful services so modelliert, dass sie einen Boundet Context implementieren, passt es immer dann gut, wenn von der Domaine aus ein synchrones API über http Sinn macht. Dies ist in unserem Umfeld sehr häufig der Fall, allerdings brauche wir in vielen Fällen auch asynchrone APIs oder hoch optimierte Implementieren, für die wir dann kein REST nehmen.
Wie implementiert Ihr Eure Services? Was hat sich bewährt und was hat sich weniger bewährt?
In meinem lokalen Umfeld haben sich Java-Implementierungen mit Spring Boot und .NET Core basierte C# Implementierungen bewährt, insbesondere im Cloud/Container-Umfeld. Im Cloud/Serverless-Umfeld setzten wir eher auf Go oder TypeScript (mit Node.js).
Wie konsumiert Ihr Eure REST-Services und wie geht Ihr am Client mit dem Thema Hypermedia um?
Unserer REST-Services werden von unseren Frontends und teilweise von anderer Services konsumiert. Viele unserer Services unterstützen Hypermedia, die Links werden dann von den Frontends interpretiert und ausgewertet. Wir generieren aber nichts, sondern die Clients müssen da Hypermedia-Format (z.B. HAL oder JSON:API) kennen und die Struktur entsprechend interpretieren.
Ein Muster, das gerade in Zeiten von Micro Services populär geworden ist, ist das Backend for Frontend. Wie denkst Du darüber?
Wir verwenden BFFs immer dann, wenn wir Daten aus mehreren physikalischen Services für ein Frontend aggregieren müssen. Dann können wir oft die Performance optimieren, indem wir die Anzahl der Remote-Calls vom Frontend optimieren und andere Optimierungen (z.B. durch Caching) einführen.
Services müssen meistens auf anderen Resourcen zugreifen – allen voran Datenbanken. Wie geht Ihr hier vor und welche Learnings gibt es?
Wir analysieren oft erstmal die Use-Cases in der Domaine und entscheiden dann, welche Art von Persistenz wir brauchen. Oft passt eine SQL-Datenbank mit entsprechendem O/R-Mapping, manchmal passt eine NO-SQL-Datenbank besser. Mit der generellen JPA-Performance hatte wir bisher noch keine Probleme.
Ein weiteres Thema, das sich sowohl über Frontend als auch das Backend spannt, ist Authentifizierung. Wie geht Ihr hier vor?
Wir setzten grundsätzlich auf Standards, wie z.B. OpenID Connect oder OAuth2. Allerdings sind wir davon abgekommen, die Authentifizierung/Autorisierung ins Frontend durchzureichen. Das haben wir früher gemacht, z.B. einen Implicit Flow von Frontend aus angestoßen. Dies birgt aber Sicherheits-Risiken, so dass wir heue Authorizing Gateways benutzen. Dabei machen die Frontends zunächst nicht autorisiert Calls an das Backend. Dazwischen sitzt ein Gateway, welches checkt, ob für die Session schon eine Autorisierung besteht. Wenn nicht, startet das Gateway eine Authorization Code Flow und cached das Token (meistens JWT) mit der Session als Key.
Wo siehst Du Herausforderungen, beim Zusammenspiel zwischen Backend und Frontend bzw. Entwickler:innen, die eher Backend- oder eher Frontend-lastig sind?
Die größte Herausforderung sehe ich darin, dass sowohl Frontends wie auch Backends immer komplizierter werden und dass es schwierig ist, in beiden Welten wirklich zu Hause zu sein. Daher finde ich es wichtig, Teams mit Backend- und Frontend-Experten zu haben, die sich gegenseitig helfen und gut zusammenarbeiten. Wichtig ist, dass ein Team zusammen an einer möglichst guten Gesamtlösung arbeiten, die sowohl Backend wie Frontend enthält.
Noch ein paar allgemeinere Fragen
Welchen Tipp würdest Du deinem 20-jahre jüngerem ich bezüglich Software Engineering geben?
Sei offen für alles, versuche Dich ständig weiterzuentwickeln und zu verbessern. Diskutiere Deinen Code mit erfahrenen Freunden und Kollegen:innen und freue Dich über jede mögliche Verbesserung Deines Codes.
Was müsste in den Ausbildungen rund um Software Engineering aus Deiner Sicht besser oder zusätzlich gelehrt werden?
Mehr Fokus auf Soft-Skills, Kommunikation und Zusammenarbeit.
Was läuft Deiner Meinung nach heutzutage im Software Engineering besser als noch vor 10 oder 20 Jahren?
Agilität ist weitgehend in der Software-Entwicklung (und auch im Business) angekommen. Das ganze Thema DevOps hat die Gräben zwischen Dev und Ops deutlich schmaler gemacht. DDD ist etabliert und hilft sehr dabei, dass Business-Leute und Software-Entwicker sich besser verstehen.
Mehr hierzu: Server Woche 🔥
Mehr zu Themen wie ✅ Micro Services, ✅ REST APIs ✅ DDD und ✅ modern Authentication erfährst Du in unserer Server-Woche, in der wir unsere Geschichte rund um Frontend-Architekturen im Backend "zu ende erzählen":