„Software-Architektur ist die Menge aller wichtigen und schwer änderbaren
Entscheidungen“, doch wie stellen wir sicher, dass wir uns im Team an einmal
getroffene Entscheidungen auch halten?
Frei nach dem Motto „Man kann nicht
keine Architektur haben“ entstehen die meisten Software-Systeme
entsprechend einer inneren Struktur. Doch gibt es große Unterschiede, wie diese Struktur definiert,
gepflegt und gelebt wird. Das kann von chaotisch fließend über nur in den Köpfen
der Entwickelnden
existierend bis hin zu klar definiert und dokumentiert in
einer entsprechenden
Architekturdokumentation reichen.
Doch nur weil etwas
im besten Fall dokumentiert ist, heißt das noch lange nicht, dass alle auch
entsprechend handeln. Stattdessen kommt es nur allzu schnell vor, dass wir aus Unwissen
oder unter
Zeitdruck gegen die selbstdefinierten Regeln verstoßen.
Um dem
entgegenzuwirken, können wir uns nun auf unser Gewissen verlassen oder hoffen,
dass es im
Code-Review schon auffallen wird. ODER wir schaffen die Möglichkeit
mit ArchUnit die
Architektur-Regeln explizit zu beschreiben und auch automatisch
auf Einhaltung zu prüfen.
Mit ArchUnit können wir Schichten und fachliche Schnitte
innerhalb unserer Software und deren
erlaubt Abhängigkeiten untereinander beschreiben
und als Teil unserer Unit-Tests automatisch
überprüfen. Gleichzeitig können wir
Regeln zur „richtigen“ Verwendung von Annotationen und
Exceptions aufstellen
und diese gemeinsam mit unserer Applikation weiterentwickeln.
Die Einhaltung
der so festgelegten Architektur-Regeln kann fortlaufend geprüft werden als Teil
der vorhandenen Testsuite.
Wünschenswertes Vorwissen:
Grundlegendes Verständnis von
* der Softwareentwicklung im Team
* Paketstrukturen und Verwendungsbeziehungen zwischen Klassen