Der modulare Monolith

Ein Test

Der modulare Monolith ist ein gängiger Architectural Style. Die Vorteile sind – was mir auf die Schnelle einfällt:

• Wiederverwendung von Funktionalität ist sehr einfach
• Änderungen, welche mehrere Komponenten betreffen, sind einfacher zu koordinieren
• Commincation Style ist sehr einfach und die Performance ist leichter vorhersehbar
• Das Deployment bzw. dessen Planung ist sehr einfach

Das schöne bei diesem Stil ist: Architekturelle Unit-Tests sind möglich. Siehe dazu folgende Blog-Einträge:

• https://travisgosselin.com/architectural-unit-testing/
• https://www.baeldung.com/java-archunit-intro

Vor einiger Zeit hab ich mir schon Roslyn angeschaut. Für mich hat sich die Frage gestellt: Was hat sich geändert? Wie leicht kann man das mit der Roslyn API realisieren? Das Demo Projekt findet man unter: https://github.com/mvodep/Playground/tree/main/Roslyn/Architecture

Points of Interest:

• Das Generieren von PlantUML ging sehr einfach
• Alle strukturellen Abfragen gehen einfach:
  • Sicherstellen, dass public Klassen Top-level sind
  • Alle Libraries eine Dokumentation haben
  • Methoden nur eine gewisse LOC haben
  • usw.

Wie könnte eine Komponente in einem modularen Monolith also ausschauen?

Codequalität sichern

Waren es vor einigen Jahren noch StyleCop und FxCop, so sind es heute Roslyn Validators. Dabei gibt es zwei wichtige Disziplinen (alle sollten automatisiert in der Build-Pipline validiert werden):

• Code Style: Das sollte einheitlich sein. Einrückungen, Klammern oder best-practices (e.g. readonly für private members wenn bereits initialisiert).
• Code Quality: Depreciated Methoden / Properties vermeiden, richtige Anwendung von TPL usw.

Die Code Qualität kann auch durch diverse Metriken gesichert werden. Hier kann man auf fertige Tools wie SonarQube, Coverity oder NDepend zurückgreifen.

Folgende Link zeigt die Regeln: https://learn.microsoft.com/en-us/visualstudio/code-quality/roslyn-analyzers-overview?view=vs-2022

Erwähnt sind auch 3rd Party Analyzers:

• https://github.com/DotNetAnalyzers/StyleCopAnalyzers
• https://github.com/josefpihrt/roslynator

Softwaremetriken

Visual Studio hat schon einige Metriken on-board. Folgende Metriken helfen den Code zu bewerten:

• Maintainability index: Wird anhand der Cyclomatic Complexity, Lines Of Code und Halstead Volume berechnet.
• Cyclomatic Complexity: Gibt die Anzahl der linear unabhängigen Pfade an.
• Class Coupling: Siehe Artikel

Fazit: Es macht Sinn, all diese Überprüfungen in die Build-Pipline einzubauen. Ein einmaliges Anwenden nach Jahren der Entwicklung ist zu wenig.