Das Dokument beschreibt ein IT-Beratungsunternehmen aus Dresden, das seit 2008 in den Bereichen Softwareentwicklung, Architekturberatung und Training tätig ist und Lösungen auf Basis von Java-Technologien bietet. Es werden Herausforderungen und Lösungen bezüglich der Systemarchitektur, insbesondere im Kontext von Skalierbarkeit und Datenanalyse, erläutert sowie ein Workshop zur Umstrukturierung von Monolithen hin zu Microservices angeboten. Zudem wird auf die Bedeutung von Softwareanalytik und der Dokumentation von Erkenntnissen für die Planung und Refaktorisierung eingegangen.

2. Wir sind ein Dresdner IT-Beratungsunternehmen,
gegründet im Jahre 2008. Unsere Schwerpunkte
liegen in den Bereichen Softwareentwicklung,
Architektur-beratung und Training. Gemeinsam
mit unseren Kunden entwerfen und
implementieren wir fachlich passgenaue Lösungen
auf Basis der Java-Technologien.
buschmais GbR
Inhaber
Torsten Busch, Frank Schwarz,
Dirk Mahler und Tobias Israel
Adresse
Leipziger Str. 93
01127 Dresden
info@buschmais.com
www.buschmais.de

4.  Eine Medaille – Zwei Seiten
◼ Hohe Komplexität, aufwendig zu pflegen
◼ Bewährtes Rückgrat betrieblicher Abläufe

5.  Geschäftliche Rahmenbedingungen ändern sich kontinuierlich
◼ Mitbewerber, Geschäftsmodelle, …
 Kann das System folgen?

6.  Grundlegende qualitative Eigenschaften
◼ Skalierbarkeit, Performanz, Sicherheit, Wartbarkeit, ...
 Manifestierung in Code und Prozessen
◼ Technologien, Strukturen, Muster, Test-Strategie, ...
 Änderungen? Aufwändig und riskant!

7.  Notwendigkeit der (kontinuierlichen) Anpassung
 Begrenztes und unsicheres Wissen
◼ Risiko für Planung, Implementierung und Refaktorisierung
◼ Kann zu Angst vor Änderungen führen
 Kontinuierliche Verschlechterung der Situation als Resultat

8. Dokumentierte Architektur
<>
Gefühlte Architektur
<>
Reale Architektur

9. Neu-Implementierung
Zerlegung in Microservices
Restruktukrierung des Mononlithen

11.  Open-Source e-Commerce System „shopizer“
◼ Warenkorb
◼ Katalog
◼ Suche
◼ Bestellung
◼ Shop-Administration
 Fork: https://github.com/buschmais/shopizer

13.  Szenario: Katalog sorgt für hohe Systemlast zu Spitzenzeiten
◼ Gesamtes System muss skaliert werden
Allokation theoretisch unnötiger Ressourcen
◼ Wettkampf um verfügbare Ressourcen
Behinderung anderer Funktionalitäten
◼ Lastbedingte Ausfälle betreffen gesamtes System

14.  Lösung
◼ Herauslösen des Katalogs
 Problem(e)
◼ Wieviel (und welcher) Code ist betroffen?
◼ Welche Schnittstellen existieren bzw. müssen geschaffen werden?
◼ Welche Daten müssen repliziert werden?
◼ Welches Vorgehen ist das richtige?
◼ …

15. https://spongebob.fandom.com/wiki/List_of_time_cards

16. https://imgflip.com/memegenerator/Skeptical-Baby

17. https://builder.cheezburger.com/Builder/RenderPreview/65f84df1-bae0-4cb8-9602-5205a7caf98d

19.  Data Analytics für Software Systeme
◼ Extraktion und Zusammenführung von Informationen aus
Source Code
Statischen und dynamischen Eigenschaften
Entwicklungshistorien
◼ Schlussfolgern von neuen Informationen zum Aufbau von Wissen

20.  Dokumentation von Erkenntnissen
◼ Unterstützung von Planung und Refaktorisierung
◼ Referenz für (neue) Entwickler
◼ Kommunikationsgrundlage für Entwickler und Entscheider

21. https://www.kino.de/serie/hoer-mal-wer-da-haemmert-1999/news/hoer-mal-wer-da-haemmert-tim-allen-bringt-neue-folgen-ins-gespraech/

22.  Tooling
◼ jQAssistant
Scan der Applikation und Abbildung in Graphdatenbank
◼ Neo4j
Persistierung und Abfrage von Informationen
◼ Jupyter Notebook
Dokumentation der Analyseschritte und Ergebnisse

24. service
:Package
Product
Service
:CONTAINS
:Type:Java
Match (:Package{name: ‘‘service“})-[:CONTAINS]->(type:Type:Java) RETURN type
Node NodeRelationship
LABEL PROPERTY LABELVAR

26.  Schier unendliche Menge an
möglichen Fragestellungen
◼ Abhängig von Ziel und Qualität
sowie Quantität der
vorliegenden Daten
https://makeameme.org/meme/possibilities-are-endless-59fa8f

27.  Wie ist die Anwendung technisch strukturiert?
 Wie ist die Anwendung fachlich strukturiert?
 Wie hängen die einzelnen Fachlichkeiten zusammen?
 Welcher Code wird am häufigsten geändert?

28. Vorbereitung der Anwendung

29. <plugin>
<groupId>com.buschmais.jqassistant</groupId>
<artifactId>jqassistant-maven-plugin</artifactId>
<version>1.6.0</version>
<executions><execution>
<goals>
<goal>scan</goal>
<goal>analyze</goal>
</goals>
</execution></executions>
<.../>
</plugin>

30. mvn clean install jqassistant:server
→ localhost:7474

31. https://www.memecreator.org/meme/lets-get-to-work81

32. Wie ist die Anwendung technisch strukturiert?

33.  Technischen Architekturelemente (z.B. Layer)
 Abhängigkeiten zwischen technischen Architekturelementen
 Umsetzung der technischen Architektur im Code
 Aussagekraft der Ergebnisse

34.  Live-Demo
◼ Abhängigkeit zwischen maven-
Modulen
◼ Zuordnung von Artefakten zu
Layern (Presentation, Domain,
Data Layer)
<<maven>>
sm-shop
<<maven>>
sm-core
<<maven>>
sm-core-modules
<<maven>>
sm-core-model

35.  Learning Outcomes
◼ die Anwendung folgt einer klassischen 3-Schichten-Architektur
◼ die Richtungen der Abhängigkeiten wurden korrekt implementiert
◼ es konnten 100% des Codes zu technischen Schichten zugeordnet
werden

36. Wie ist die Anwendung fachlich strukturiert?

37.  Implementierte Subdomänen
 Fachliche Architekturelemente (z.B. Module)
 Umsetzung der fachlichen Architektur im Code
 Aussagekraft der Ergebnisse

38.  Wo ist eine gute fachliche Strukturierung am ehesten zu
erwarten?
◼ Spring-Services
◼ Paketnamen (service, konkrete Fachlichkeiten wenn bekannt)
◼ Explorieren der Anwendung in IDE

39.  Live-Demo
◼ Fachliche Packages
(Subdomänen)
◼ Zuordnung von Klassen zu
Subdomänen anhand Package-
Namen
Classes
catalog common content customer
merchant order payments reference
search shipping shoppingcart system
tax user

40.  Learning Outcomes
◼ die Geschäftslogik teilt sich in 13 fachlich motivierte Subdomänen
◼ es konnten 69% aller Klassen zu Fachlichkeiten zugeordnet werden
◼ der Katalog ist mit 140 Klassen die größte Subdomäne

41. Wie hängen die Fachlichkeiten zusammen?

42.  Existierende Abhängigkeiten zwischen Subdomänen
◼ Erlaubte und Unerwartete/Verbotene Abhängigkeiten
◼ Anzahl an Abhängigkeiten
◼ Hot Spots

43.  Live-Demo
◼ Visualisierung von
Abhängigkeiten
◼ Analyse von
Ein- und Ausgehenden
Abhängigkeiten
Kopplungsgrad
Hot-Spot Klassen

44.  Learning Outcomes
◼ die Suche gehört exklusiv zum Katalog
◼ die Kommunikation zwischen Katalog und Kern ist schwach durch
Interfaces entkoppelt

45.  Learning Outcomes
◼ der Katalog definiert 169 Abhängigkeiten zum Kern auf Klassenebene,
27 davon gegen Interfaces
Hot Spots sind MerchantStore und Language

46.  Learning Outcomes
◼ der Kern definiert 162 Abhängigkeiten zum Katalog auf Klassenebene,
5 davon gegen Interfaces
Hot Spot ist Product

47. War‘s das?

48.  Software Analytics bietet nahezu unbegrenzte Möglichkeiten
 Analyse abhängig von
◼ betrachtetem Softwaresystem
◼ vorhandenen Daten
◼ Fragestellungen

49.  Weitere Analysen
◼ Ownership von Subdomänen, Fix-Commits
◼ Testcoverage, Teststruktur
◼ Defektdichten
◼ Toter Code
◼ Analyse von Laufzeitdaten
◼ ...

50.  Bewertung der Ergebnisse notwendig
◼ Tiefergehende Analysen für kritische Stellen
◼ Relevanz und Priorisierung
◼ Planung von Refaktorisierung und Implementierung
◼ Management von Technical Debt

51.  2-Tages Workshop
 Strukturiert vom Monolithen zum
Modulithen und Microservices
 Interaktiv am Beispiel eines e-
Commerce Shopsystems
 Nächster Termin: November 2019
https://www.buschmais.de/seminare/lasst-uns-einen-monolithen-zerlegen/

53. Fragen bitte an: Stephan Pirnbaum
buschmais GbR
Inhaber
Torsten Busch, Frank Schwarz,
Dirk Mahler und Tobias Israel
stephan.pirnbaum@buschmais.com
http://buschmais.de/
Dresden, 21.05.2019