Zur Modellierung und Validierung von Softwarearchitektur verwenden wir das Tool "SonarJ". Im Anschluss lest ihr eine Mail an mein Team aus dem "42" Projekt, das auf Architekturverletzungen und damit verbundene, von mir bereits teilweise durchgeführte Refactorings verweist und aufzeigt, welche zusätzlichen Schritte zu setzen sind, um die bestehenden Architekturverletzungen zu beheben. Sehr schön sieht man wieder einmal, dass das schönste Architekturmodell ohne automatische Validierung nicht eingehalten werden kann und sich im Prozess der Entwicklung sub-optimale Designentscheidungen und daraus folgende Implementierungen nicht "up-front" vermeiden lassen. Aber lest selbst...
Ein frappantes Ergebnis des SonarJ Durchlaufs war eine Abhängigkeit vom Backend auf den Layer „view“ - das ist natürlich immer strengstens verboten, ist aber 3x im Code vorgekommen! Ich habe das klarerweise sofort behoben.
mfg
---- mail snippet ----
Euer JWR@coopxarch.
---- mail snippet ----
Hallo 42-Team!
Nachdem ich gerade mit SonarJ für ein anderes Projekt arbeite, hab ich auch gleich die 42-Software einem Architektur-Review unterzogen und ein paar unschöne Abhängigkeiten entfernt:
Das ist die definierte Architektur (horizontale Box = Layer; vertikale Box = Domain-Bereich) mit den in grün eingezeichneten erlaubten Abhängigkeitsbeziehungen – links von oben nach unten, rechts von unten nach oben (eine Abhängigkeit vom Backend auf den Layer „view“ ist z.B. verboten):
Nachdem es nun keine Abhängigkeiten auf den layer „view“ mehr gibt, könnte man das Projekt gänzlich ohne den View Layer "at.*****.client" im Klassenpfad kompilieren und die Backend Tests fahren – wer will, kann’s ja ausprobieren.
Folgende Architekturverletzungen gibt es noch (in rot auf der rechten Seite der Layer eingezeichnet):
Die Layer „model“ und „service“ greifen auf „remoting“ zu, was natürlich auch zu vermeiden wäre – der Grund sind die DTOs (i.e. die „*Info“ Klassen), die wir in den 3(!) Layern "remoting", "service" und "model" definiert haben:
AuctionServiceImpl.java befüllt ein AuctionInfo und das referenziert auf VehicleInfo(s).
Die Verstreuung der *Info Klassen sollte man natürlich auch in den Griff bekommen, allerdings gibt es im Backend sehr viele weitere zyklische Abhängigkeiten, sodass nach Beseitigung der Abhängigkeiten nur die Layer „remote" und "controller“ unabhängig würden, das Backend mit "data-access", "model" und "service" bliebe aber nur monolithisch verwendbar.
Hier nochmal alle nicht erlaubten Abhängigkeiten:
Diese Architekturverletzungen müssen noch systematisch durch Refactoring behoben werden.
Hannes.
Keine Kommentare:
Kommentar veröffentlichen