Interview mit Matthias Bohlen

„Mit DDD kommt man schnell von einer konzeptionellen Diskussion in den Code“
Keine Kommentare

Domain-driven Design ist in aktuellen Diskussionen zu Software-Architektur nicht mehr weg zu denken. Wir haben uns mit Matthias Bohlen, DDD-Experte und Trainer des DDD Camps, über die Gründe für DDD unterhalten. Außerdem klären wir, was eine zeitgemäße Architektur ausmacht und welche Themen jenseits der Trends und Hypes beachtet werden sollten.

Wir wollen uns über zeitgemäße Software-Architektur unterhalten. Wenn wir zunächst einmal beim Wort „zeitgemäß“ bleiben: Was macht eine zeitgemäße Architektur aus?

Matthias Bohlen: Zeitgemäß heißt für mich zwei Dinge: einerseits nach den heute geltenden Qualitätsanforderungen des Vorhabens (also des Projekts oder Produkts), andererseits auch zeitgemäß im Sinne von “nach den aktuellen Regeln der Kunst”. Vorhaben beginnen, indem ein Team mit seinen Stakeholdern eine gewisse Einschätzung der benötigten Qualitäten hat, also „wie performant, wie sicher, wie benutzbar, wie wartbar, wie portabel, skalierbar, usw. muss das Ganze denn werden?“.

Diese Einschätzung ändert sich laufend. Beispiel: Jemand findet, die Anwendung sei nicht performant genug und baut deshalb einen Cache ein. Nach zwei Wochen beschweren sich die ersten Benutzer, dass die angezeigten Daten nicht mehr wirklich aktuell sind (Programmierfehler oder ein Missverständnis beim Einbau des Caches?). Dann könnte das Team auf die Idee kommen, lieber verständlichen, wartbaren Code zu wollen anstatt eine so hohe Performance, die man ja vielleicht auch auf andere Weise erreichen könnte, und sie bauen den Cache eben wieder aus.

Ein anderes Beispiel wäre die Anbindung mobiler Geräte. Die Architektur muss sich dann manchmal verändern und für die kleinen Geräte extra Backends anbieten, damit es die Frontends nicht so schwer haben.

Der andere Aspekt, den ich genannt hatte (Entwerfen nach den aktuellen Regeln der Kunst) verändert sich auch ständig: Eine Zeit lang wollten viele Teams Microservices machen, weil das auf sämtlichen IT-Konferenzen diskutiert wurde. Mittlerweile hat man gesehen, welche Komplexität das mit sich bringt, und Teams fragen sich eben heute: Müssen wir denn unbedingt ein so feingranulares Deployment haben, wie es Microservices anbieten? Reichen nicht etwas größere Subsysteme aus, mit Schnittstellen, die dadurch wesentlich leichter zu handhaben sind als die von Microservices?

Dasselbe gilt für fortgeschrittene Konzepte wie CQRS, Event Sourcing, Event-driven, usw. In meinen Trainings zeige ich, dass man das nicht großflächig als Architektur einführen muss, sondern auch lokal entscheiden kann, an welcher Stelle im System man CQRS/ES einsetzt, und an welcher Stelle eher klassische Zustandshaltung. Und ob man nun unbedingt alles “Event-driven” machen muss, ist auch nicht selbstverständlich, sondern situationsabhängig.

Welche Herausforderungen an Software-Architekturen sind in den letzten Jahren neu hinzugekommen?

Matthias Bohlen: Mobile Geräte sind ja nun schon lange da, doch für Enterprises sind sie immer noch herausfordernd. Die Denkweise: “Lieber einen kleinen Use Case richtig mobilisieren, als eine große Anwendung auf das Mobildings zu bringen”, hat sich noch nicht wirklich durchgesetzt. Das bewirkt Usability-Probleme ohne Ende.

Beispiel: Die aktuellen Sicherheitsanforderungen im Banken-Umfeld gehen mir als Anwender mehr und mehr auf die Nerven. Manche Banken investieren zu wenig darin, die Anwender zu beobachten und wundern sich, warum die Kunden zu “moderneren Banken” oder zu Apple Pay abwandern. Beispiel: Ich will eine Überweisung machen. Meine Bank bietet mir dafür eine mobile App und zusätzlich eine zweite App, mit der ich TANs generieren muss, die ich dann mühsam in die erste App abtippen muss, um die Überweisung abzuschließen. Man glaubt nicht, dass wir im Jahr 2021 leben.

Weitere Challenge: Die Passwörter. Ich habe einen Passwort-Manager, in dem ich pro Bank drei Passwörter halten muss: eins für die Banking App, eins für die TAN-App, eins für die Spezial-App, die nur dann in Aktion tritt, wenn ich mit Kreditkarte zahle, nicht bei Überweisungen. Haben wir tatsächlich 2021?

Der Konflikt “Benutzbarkeit versus Sicherheit” wird traditionelle Unternehmen immer stärker beschäftigen, weil sie von kleinen, innovativen Unternehmen rechts überholt werden. Die Kleinen haben diesen Konflikt anerkannt, tiefgehend verstanden und dann konsequent gelöst.

Microservices Summit - Das große Online-Trainingsevent für Microservices, DevOps, Continuous Delivery, Docker & Cloud
Thilo Frotscher

Microservices mit Service Mesh: Hands-on mit Istio

Workshop mit Sascha Selzer und Tammo van Lessen (INNOQ)

Lars Röwekamp

Shared Data in verteilten Architekturen

Workshop mit Lars Röwekamp (Open Knowledge GmbH)

Architektur-Trend Domain-driven Design

Auf dem DDD Camp geht es konzentriert um Domain-driven Design. Was findest du persönlich spannend daran?

Matthias Bohlen: Für mich ist spannend, wie eine zusammengewürfelte Truppe von Leuten gemeinsam per DDD in einem kurzen Hackathon von drei Tagen eine Anwendung aus dem Boden stampft, die wirklich etwas Sinnvolles tut. Die Teilnehmer:innen nutzen DDD, um schnell von einer konzeptionellen Diskussion des Themas in den Code zu kommen – das finde ich faszinierend!

Die Leute haben im Camp gesehen, wie einfach es eigentlich sein könnte und werden dann versuchen, es im Alltag ähnlich gut hinzubekommen.

Sie werden gut mit den Fachleuten zusammenarbeiten und sich im Team Regeln geben, wie Domänenbausteine umzusetzen sind, damit sie in der eigenen Firma eben die Ideen auch schnell vom letzten Meeting in den Code bringen, um frühzeitig Feedback zu bekommen und dann mit hoher Qualität die Sache zu Ende zu entwickeln.

Die Leute im Camp erleben auch, wie DDD mit seinen Standardbausteinen die Team-Zusammenarbeit verbessern kann. Beispiel: Ein Paar schnappt sich ein Aggregate zur Umsetzung, ein anderes Paar nimmt sich ein weiteres Aggregate, jeweils mit einem Service oben drüber und einem Repo unten drunter. Das geht nach kurzer Übungszeit wie der Blitz und sorgt für klare Verantwortung in der Teamarbeit!

Welcher Trend der Software-Architektur – abgesehen von DDD – wird deiner Einschätzung nach im Jahr 2021 Fahrt aufnehmen?

Matthias Bohlen: “Voraussagen sind schwierig, besonders wenn sie die Zukunft betreffen”, das sollen sowohl Karl Valentin als auch Nils Bohr gesagt haben. 🙂

Wenn ich mal in die Glaskugel schaue, dann sehe ich, dass Corona noch eine Weile bei uns bleiben wird und deshalb das Thema Remote-Zusammenarbeit weiter stark im Kommen sein wird. Auch wenn Corona eines Tages besiegt sein sollte, werden die Unternehmen nicht einfach zur Präsenzarbeit zurückkehren wie vorher.

Das bedeutet, die Softwaresysteme müssen Kollaboration aus der Ferne besser unterstützen. Die Use Cases werden sich genau in diese Richtung verändern, und die Architekturen müssen sich anpassen, indem sie weniger zentralistisch gestaltet sein müssen.

Beispiel: Eine Person sollte selbst flexibel entscheiden können, für welche Firma sie heute von 11–13 Uhr arbeitet und dann von 15–17 Uhr vielleicht für eine andere Firma. Versuch das einmal mit Microsoft Teams zu lösen: Du wirst feststellen, dass der MS-Teams-Admin der Firma 1 es seinen Leuten verbieten kann, sich später in eine Videokonferenz von Firma 2 einzuwählen. Fehlermeldung in MS Teams: “You cannot get there from here!”. Was Corona uns gezeigt hat: Es gibt ab jetzt eben kein “there” und kein “here” mehr – das ist vorbei, aus!

Ich bezweifle aber, dass das in 2021 bei den Großunternehmen Traktion bekommt, dafür sind sie einfach zu langsam. Auch hier besteht die Gefahr, von den kleineren, innovativeren Unternehmen rechts überholt zu werden. Für die Kleinen und Mittelgroßen ist das wunderbar, es eröffnen sich völlig neue Chancen!

Für uns Softwarearchitekten heißt das, wir müssen unsere Köpfe flexibler machen, damit unsere Architekturen flexibler werden.

Welches Architektur-Thema abseits der Hypes und Trends sollte deiner Meinung nach eine größere Beachtung finden?

Matthias Bohlen: Systematisierung der Prozesse in den Teams: Wenn Du als Entwickler ein System hinter dem hast, was Du tust, dann brauchst Du nicht jedesmal nachzudenken, wie Du etwas löst. Du kannst vieles wiederholbar machen, z.B. Autorisierung, Validierung, API-Gestaltung, Speicherung, optische Darstellung im Frontend, usw.

Warum sollte ein Entwickler z.B. immer wieder darüber nachdenken, wie man das UI macht? Ein System muss her: grobe Navigation links, feine Navigation oben, dann eine Liste, aus der man einen Eintrag anwählt, zu dem dann die Details dargestellt werden. Mit dem Back-Button des Browsers einfach zurück zur Liste, und fertig!

Die Benutzer fühlen sich wohler, und die Entwickler haben weniger Arbeit, wenn solche Dinge in einem Design-System festgehalten sind, das durch Fertigkomponenten in Front- und Backend unterstützt wird.

Das Backend braucht eine gewisse Architektur, damit es diese Fertigkomponenten des UIs versorgen kann. Diese “Fertigteile-Architektur” muss man möglichst schnell anstreben, um sich auf die kreative, Werkstatt-artige Arbeit mit den Domänenexperten konzentrieren zu können. Dann macht das gemeinsame Entwickeln mit Fach- und IT-Seite so richtig Spaß, sowohl technisch als auch finanziell.

Vielen Dank für dieses Interview!

Matthias Bohlen ist Experte für effektive Produktentwicklung. Er hat als Coach, Consultant und Trainer für Entwicklungsorganisationen aus den Branchen Energie, Touristik, Logistik, Automotive, Telekom, Versicherungen und Gesundheitswesen gearbeitet. Matthias Bohlen hilft Führungskräften und Teams, ihre Performance zu verbessern, Ziele zu erreichen und die Zufriedenheit von Kunden und Mitarbeitern gleichermaßen zu erhöhen.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -