Im Gespräch mit Peter Gafert zu ArchUnit und seinem Vortrag "Gemeinsam gegen den Ball-of-Mud"

(Alex) “Hallo Peter. Ich freue mich, dass wir heute über deinen Vortrag am Architektur-Punsch quatschen. Vielleicht magst du dich mal kurz vorstellen."

Peter: “Ich bin in Peter Gafert und arbeite seit mittlerweile elf Jahren als Principal Consultant bei TNG Technology Consulting in München und habe über die Zeit viele verschiedene Software-Projekte begleiten dürfen - und auch sehen dürfen, wie sich solche Projekte über die Zeit entwickeln und was es für Herausforderungen gibt. Irgendwann ist aus einem solchen Projekt meine Idee für ArchUnit entstanden, worüber ich ein bisschen was in meinem Vortrag erzählen werde.”

(Alex) “Magst du vielleicht kurz erzählen, was ArchUnit eigentlich ist?"

Peter: “ArchUnit ist eine Library für Java-Projekte (bzw. JVM-Projekte die statisch kompiliert sind) um Architektur zu testen. Das heißt, ich kann in automatisierten Tests ausdrücken: Was für Komponenten habe ich eigentlich? Was für Muster habe ich in meiner Anwendung? Wie sollen die Komponenten voneinander abhängen dürfen? Ich kann viele Konventionen und Strukturen automatisiert sicherstellen. Das ist ein großer Vorteil, weil ich jetzt eine sehr schnelle Feedback-Loop habe. Wenn neue Leute ins Projekt kommen, dann können wir halt sicherstellen, dass nicht irgendwelche Utilities und Controller benutzt werden oder ähnliche Sachen. Oder wir können aufzeigen, dass wir eigentlich immer das Builder-Pattern für gewisse Komponenten benutzen. Nützlich ist es aber auch für erfahrene Leute. Also ich meine, wenn ich selber Tests schreibe, gehen die auch manchmal schief, wenn ich selbst den Code weiterentwickeln will. Weil manchmal sind viele Sachen halt einfach, wenn man irgendwie herumdoktert an so einer Codebasis. Und eigentlich, wenn man aus einem höheren Level strukturell draufschaut, hat man es vielleicht dann doch suboptimal gemacht. Oder eigentlich gegen die Konventionen, die man einhalten wollte. Dabei kann ArchUnit helfen. Man kann es einfach als Unit-Test runterschreiben in einer recht einfachen Fluent-API, was ich dann auch zeigen würde. Außerdem zeige ich, welche Regeln so möglich sind und wie wir sicherstellen, dass es auf Dauer einfach als Dokumentation im Code aktuell bleibt und der Code nicht degeneriert über die Zeit.”

(Alex) “Der eine oder die andere haben dich ja vielleicht schon über ArchUnit sprechen gehört. Da hast du viel über die Implementierung von Architektur-Tests gesprochen. Aber was mir an deinem Vortrag am Architektur-Punsch sehr gut gefällt, ist, dass er das Thema auch etwas von der methodischen Seite beleuchtet. Was hat dich dazu motiviert, das Thema anzugehen?"

Peter: “Ich habe halt einfach das Gefühl, dass es relativ einfach ist, technisches Hintergrundwissen zu ArchUnit zu bekommen, z.B.: Was gibt diese Fluent-API her? Oder wie schreibt man solche Tests? Aber ich habe so ein bisschen das Gefühl, dass es halt einfach eine Hürde gibt, wie man das wirklich konkret umsetzt. Wie man wirklich im Alltag, wenn man Diskussionen hat oder wenn sich das Projekt entwickelt, diese Sachen ganz konkret und effizient passend, als Code modelliert. Es ist ein Abstraktions-Transfer-Schritt, und ich habe das Gefühl, dazu gibt es nicht so viel Doku. Deswegen wollte ich einfach die Seite mal beleuchten und es mal näher bringen. Wie integriere ich das wirklich in meinen Prozess, und wie begleitet das so eine fiktive Architektur über Zeit? Wie mache ich das mit meinem Team?”

(Alex) “Modulare Monolithen und Modulithen erleben gerade eine Renaissance. Gewinnt ArchUnit dadurch an Wichtigkeit?"

Peter: “Ja, würde ich auf jeden Fall so sehen. Ich meine, bei Microservices wird halt eine gewisse Menge des Systems aufs Netzwerk verlagert und an der Stelle kann man es natürlich mit ArchUnit nicht mehr testen, weil ArchUnit auf den Bytecode angewiesen ist. Wenn ich die Sachen zurückverlagere in den Code, z.B. wie sprechen die Komponenten miteinander, welche Interfaces rufen die auf. Wenn ich das wieder statisch überprüfen kann, dann habe ich natürlich da wesentlich mehr Kontrolle. In der Microservices-Welt kann ich halt schauen, dass vielleicht die Dinger untereinander strukturell ähnlich sind, wenn ich nicht total auswuchern will. Und die Frage ist natürlich immer, wie groß ist ein Microservice? Wenn die alle 100 bis 200.000 Zeilen Code haben, dann gewinne ich ja auch da was, wenn ich schaue, dass die gut strukturiert sind. Aber in einem modularen Monolithen habe ich natürlich noch einen viel größeren Hebelpunkt und ich kann auch ArchUnit benutzen, um so ein bisschen den Weg offen zu halten, falls ich eben doch das System später noch mal teilen will. Wenn man sowas wie evolutionäre Zellteilung machen will, dass ich irgendwann sehe, dass sich eigentlich zwei Business Kontexte, die sehr groß sind, mittlerweile da drin gefunden, lass doch mal einmal teilen und nicht in tausend Kubernetes-Nanoservices oder so. Hat ja alles seine Vor- und Nachteile. Aber für Modulithen, denke ich, ist ArchUnit wirklich ein sehr hilfreiches Tool. Sieht man auch daran, dass es mittlerweile schon ein paar Libraries gibt, zum Beispiel das Moduliths-Projekt, wo man auf Spring-Basis einfach modulare Monolithen bauen kann, wo auch ArchUnit schon integriert ist.”

(Alex) “Jetzt haben wir ja schon ein bisschen über Trends gesprochen. Was habt ihr denn so geplant für die Zukunft von ArchUnit? Gibt es vielleicht noch andere wichtige Trends, die da eine Rolle spielen?"

Peter: “Das eine ist natürlich, die APIs noch mächtiger und einfacher zu machen. Aber es gibt halt viele Sachen, die aus Zeitgründen oder so bisher runterpriorisiert wurden, um für 1.0 einen stabilen Kern zu bekommen, wo halt Konzepte wie Generics, Lambdas und so weiter korrekt unterstützt werden. Und der andere Bereich ist eine Modul-API, wo man irgendwie noch mächtiger und einfacher Module für seine Anwendungen definieren kann, die automatisiert geprüft werden und vielleicht so ein paar Best Practices haben. Und ich würde gerne endlich mal was Richtung Visualisierung angehen. Dass man irgendwie einfache Sachen auch visuell darstellen kann und vielleicht Diagramme generieren kann. Out of the box. Ich meine, es geht tatsächlich schon mit sehr wenig Code an sich, aber es ist halt nicht so richtig benutzbar, wenn man halt irgendwie jedes Mal nachschauen, wie rendert man das jetzt oder was muss man genau machen mit der Core-API.”

(Alex) “Ich würde gern mit einem kurzen Teaser für deinen Talk abschließen. Und zwar sprichst du im Abstract auch darüber, wie man ArchUnit in Teams und in Organisationen etablieren kann. Hast du da vielleicht Erfahrungen oder Gedanken dazu, die du dem Publikum hier noch auf den Weg geben möchtest?"

Peter: “Das Wichtigste für mich ist halt, irgendwie so ein lebendes Gemeinschaftsprojekt zu schaffen. Man kann halt mit ArchUnit sicherstellen, dass man nicht versehentlich von den Konventionen abweicht. Aber manchmal hab ich das Gefühl, Leute wollen es vielleicht so ein bisschen als Kontroll-Tool verwenden oder ähnliches. Ich würde halt ein bisschen drüber reden, eher Leute mitzunehmen, zu schauen, dass man die Leute abholt, dass sie mit dabei sind und das deshalb auch gut finden und verstehen. Es ist, glaube ich, ganz wichtig, weil man halt im Endeffekt meint, man kann jede Metrik, jede Regel irgendwie umgehen, wenn man es darauf anlegt. Deswegen, glaube ich, muss man den Support halt von den Leuten auch haben, es gut machen zu wollen und nicht nur den Test grün machen zu wollen. Das wird eine Gefahr, die ich sehe. Aber man kann das Hirn ja trotzdem nicht ausschalten und einfach nur drauf los optimieren, dass halt die Tests grün sind. Das wäre so ein bisschen ein Teil, über den ich gerne reden würde.”

(Alex) “Die Mindset-Frage ist auf jeden Fall sehr wichtig. Ich würde sagen, wenn ihr da mehr von hören wollt: Peter spricht am 15.12. an am Architektur Punsch. Links zur Anmeldung werden wir auch hier im Blogpost noch mit reinstellen. Und ansonsten bleibt mir nur noch Danke zu sagen, Peter. Und ich freue mich total auf Dezember."

Peter: “Ich mich auch. Und danke dir. Ciao.”

Noch mehr Anregungen erhaltet Ihr am 15. Dezember 2022 bei unserem Architektur-Punsch. Einfach anmelden! Neben dem Vortrag von Peter gibt es dort viele weitere spannende Programmpunkte zu entdecken.

Save the date…

Architektur-Punsch 2022