Software Architecture Summit: Hallo Peter! Du wirst auf dem Software Architecture Summit einen Workshop über ArchUnit halten. Was ist ArchUnit genau? Für welche Use Cases kann man das Tool einsetzen?
Peter Gafert: ArchUnit ist eine Java-Library, mit der sich automatisiert Architektur testen lässt. Das Ganze funktioniert wie ein normaler Unit-Test: Bytecode wird eingelesen und ein Domänenmodell erzeugt, auf dem man dann Dinge testen kann. Damit lassen sich sehr knapp Regeln automatisiert testen, beispielsweise „Package x darf nicht auf Package y zugreifen“ oder „Klassen, die mit @Controller annotiert sind, sollten einen Namen haben, der auf ‘Controller‘ endet“.
Software Architecture Summit: Wie unterscheidet sich ArchUnit von anderen Tools oder Frameworks zur Architekturprüfung?
Peter Gafert: Einer der Hauptunterschiede zu anderen Architekturtest-Tools ist, dass ArchUnit sich sehr einfach in bestehende Unit-Tests einfügt und auf einfachem Java-Code basiert, den Entwickler schreiben und debuggen können. Damit lässt es sich auch sehr einfach in bestehende CI-Umgebungen integrieren und findet typischerweise schnell Akzeptanz bei Entwicklern. Abgesehen davon ist ArchUnit dadurch, dass Regeln direkt in Java geschrieben werden, auch sehr mächtig, da die volle Bandbreite der Programmiersprache genutzt werden kann.
Software Architecture Summit: Wie flexibel ist ArchUnit in Bezug auf die Anpassung an verschiedene Architekturstile und -muster?
Peter Gafert: ArchUnit ist extrem flexibel, da Regeln direkt in Java ausgedrückt werden. Außerdem baut sich ArchUnit aus einer Art Schichtenmodell mit unterschiedlichem Abstraktionslevel auf. Wenn etwas auf einem Level fehlt, kann man sich typischerweise beim nächstniedrigeren Level bedienen und ergänzen, was einem fehlt. Die direkt bereitgestellten Regeln für Schichten- und Onion-Architektur sind beispielsweise so aufgebaut. Ein beliebiger eigener Architekturstil kann auf ähnliche Weise mit etwas angepasstem Code getestet werden.
Software Architecture Summit: Kannst du uns einige typische Fallstricke nennen, die bei realen Projekten mit ArchUnit auftreten können?
Peter Gafert: Ein typisches Problem ist, dass an manchen Stellen der Bytecode, den ArchUnit analysiert, und der Source Code nicht ganz übereinstimmen. Dann kann es sein, dass man ein wenig um das Problem herumarbeiten muss. Ein anderes Problem in der Praxis ist das Abholen aller beteiligten Entwickler, die Regeln kontinuierlich zu hinterfragen und bei Bedarf zu verbessern, anstatt ihnen blind zu folgen. Dass man Architektur automatisch testen kann, führt nicht auch automatisch zu guter Architektur. Nur wenn Regeln nach guten Konzepten erstellt werden, bekommt man auch den ROI.
Software Architecture Summit: Welche Themen willst im Workshop behandeln? Worauf möchtest du einen besonderen Fokus legen?
Peter Gafert: Ich möchte einen breiten Überblick über die verschiedenen Abstraktionsebenen und Möglichkeiten von ArchUnit geben und den Teilnehmern ermöglichen, sich ihre Schwerpunkte bei den Übungen selbst zu setzen. Die Teilnehmer sollen ein gutes Gefühl dafür bekommen, wie ArchUnit „tickt“, und hinterher zügig Konzepte aus dem Kopf in Code gießen können. Außerdem möchte ich für einige Fallstricke sensibilisieren und Techniken an die Hand geben, wie man mit solchen Dingen in der Praxis umgeht.
Software Architecture Summit: Vielen Dank für das Interview!
