\nProjekt:<\/strong>\u00a0Plattform f\u00fcr die n\u00e4chste Generation der Lieferkette und des Katalogs
\nAusgangszustand:<\/strong>
\nDas architektonische Modell der Plattform hatte sich \u00fcber drei Jahre organisch entwickelt. Es enthielt \u00fcber 400 Klassen, Dutzende von Anwendungsf\u00e4llen und mehrere miteinander verkn\u00fcpfte Diagramme, die \u00fcber verschiedene Repositories verteilt waren. Zu den zentralen Problemen geh\u00f6rten:<\/p>\n
- \n
- \n
Unkontrollierte Sichtbarkeit \u00fcber Subsysteme hinweg, was zu unbeabsichtigter API-Exposition f\u00fchrte<\/p>\n<\/li>\n
- \n
H\u00e4ufige Namenskonflikte bei der Integration von Drittanbieter-Registern mit internen Buchf\u00fchrungen<\/p>\n<\/li>\n
- \n
Zweiseitige Abh\u00e4ngigkeiten, die architektonische Kopplung erzeugten und die unabh\u00e4ngige Bereitstellung erschwerten<\/p>\n<\/li>\n
- \n
Inkonsistente Diagrammnotation, die die \u00dcberpr\u00fcfungen zwischen Teams fehleranf\u00e4llig und zeitaufwendig machte<\/p>\n<\/li>\n<\/ul>\n
Ziel:<\/strong>
\nDas Systemmodell neu strukturieren, indem UML 2.0-Paketsprinzipien angewendet werden, um klare Grenzen zu schaffen, die Sichtbarkeit explizit zu verwalten, Namensraumkonflikte zu l\u00f6sen und einen wiederholbaren, diagramm-als-code-basierten Workflow f\u00fcr die architektonische Dokumentation einzurichten.<\/p>\n
\nPhase 1: Schaffung struktureller Grenzen<\/h2>\n
Das Architekturteam begann damit, die\u00a0Regel der exklusiven Eigentumschaft<\/strong>: jedes Modell-Element wurde genau einem Paket zugewiesen. Dies beseitigte mehrdeutige Referenzen und kl\u00e4rte die Verantwortlichkeit. Sie erkannten, dass ein\u00a0Modell<\/em>\u00a0selbst ist einfach ein Paket auf oberster Ebene und fungiert als Stammcontainer f\u00fcr alle untergeordneten Unterpakete.<\/p>\n
Wesentlich war, dass das Team Pakete als\u00a0konzeptionelle Grenzen<\/strong>\u00a0und nicht als physische Bereitstellungseinheiten betrachtete. Obwohl Pakete die Modulgrenzen und Build-Konfigurationen beeinflussten, zwangen sie keine strikte Eins-zu-Eins-Zuordnung zu kompilierten Artefakten. Diese Flexibilit\u00e4t erm\u00f6glichte es, logische Gruppierungen unabh\u00e4ngig von der Laufzeitinfrastruktur zu entwickeln.<\/p>\n
Um die Diagrammkomplexit\u00e4t zu managen, standardisierte das Team auf drei UML 2.0-Visualisierungssymbole:<\/p>\n
- \n
- \n
Mitglieder versteckt<\/strong>: Wird f\u00fcr \u00dcberpr\u00fcfungen der Architektur auf hoher Ebene verwendet. Der Paketname erschien zentriert im Ordnerk\u00f6rper und versteckte interne Details, um die kognitive Belastung zu reduzieren.<\/p>\n<\/li>\n
- \n
Mitglieder intern sichtbar<\/strong>: Eingesetzt w\u00e4hrend der Subsystem-Design-Sitzungen. Der Paketname befand sich im oberen Tab, wobei die enthaltenen Elemente innerhalb des Ordners aufgelistet waren.<\/p>\n<\/li>\n
- \n
Mitglieder extern sichtbar<\/strong>: Reserviert f\u00fcr Abh\u00e4ngigkeitsanalyse. Elemente wurden au\u00dferhalb des Ordners gezeichnet und \u00fcber feste Linien innerhalb einer umgebenden Box verbunden, um Wechselwirkungen zwischen Paketen hervorzuheben.<\/p>\n<\/li>\n<\/ol>\n
\nPhase 2: Steuerung der Sichtbarkeit und Verwaltung von Abh\u00e4ngigkeiten<\/h2>\n
Mit den strukturellen Containern an Ort und Stelle setzte das Team strenge Zugriffssteuerungen mithilfe von UML-Sichtbarkeitsmarkierungen durch:<\/p>\n
- \n
- \n
\u00d6ffentlich (
+<\/code>)<\/strong>: Wird auf Elemente angewendet, die bewusst f\u00fcr Interaktionen zwischen Paketen freigegeben werden.<\/p>\n<\/li>\n- \n
Privat (
-<\/code>)<\/strong>: Eingeschr\u00e4nkt auf die interne Nutzung innerhalb des Pakets und sch\u00fctzt Implementierungsdetails vor externen Verbrauchern.<\/p>\n<\/li>\n<\/ul>\nUm die Kommunikation zwischen Paketen zu steuern, ersetzte das Team willk\u00fcrliche Referenzen durch explizite, stereotypisierte Abh\u00e4ngigkeiten:<\/p>\n
Element-Import gegen\u00fcber Element-Zugriff<\/h3>\n
Wenn die\u00a0
Web-Anwendungsmotor<\/code>\u00a0katalogdaten ben\u00f6tigte, verwendete das Team eine\u00a0\u00abimport\u00bb<\/code>\u00a0(\u00d6ffentlicher Import)<\/strong>\u00a0Beziehung. Dies zog \u00f6ffentliche Elemente wie\u00a0+Buch<\/code>\u00a0und\u00a0+Autor<\/code>\u00a0in die Web-Ebene ein, wodurch sie automatisch f\u00fcr nachfolgende Verbraucher sichtbar wurden. Im Gegenteil wurden Sicherheits-Utilities \u00fcber\u00a0\u00abaccess\u00bb<\/code>\u00a0(Privater Zugriff)<\/strong>, wodurch der Web-Motor Validierungs-Routinen f\u00fcr Tresore nutzen konnte, ohne sie erneut in die \u00f6ffentliche Schnittstelle zu exportieren.<\/p>\nPaket-Import<\/h3>\n
Anstatt einzelne Elemente einzeln zu importieren, nutzte das Team\u00a0Paketimport<\/strong>auf der Subsystem-Ebene. Eine einzelne
\u00abimport\u00bb<\/code>Abh\u00e4ngigkeitszeile zwischen zwei Paketordnern erm\u00f6glichte dem importierenden Paket, alle \u00f6ffentlichen Inhalte des Zielpakets als lokal deklariert zu behandeln, wodurch die Diagrammverwirrung deutlich reduziert wurde.<\/p>\n
\nPhase 3: Behebung von Namensraum-Kollisionen und Erweiterung von Frameworks<\/h2>\n
W\u00e4hrend der Integration stie\u00df das Team auf eine klassische Namensraum-Kollision: sowohl das
Bestandsbuch<\/code>als auchVerleger-Register<\/code>enthielt eine Klasse namensBuch<\/code>.<\/p>\nUm die Modellintegrit\u00e4t zu gew\u00e4hrleisten, wandten sie zun\u00e4chst anAliasing<\/strong>, wobei der externe
Registry::Buch<\/code>auf einen lokalen Pseudonym (RegistryBuch<\/code>) innerhalb des Buchhaltungspakets abgebildet wurde. Obwohl dies funktional korrekt war, erkannte das Team, dass \u00fcberm\u00e4\u00dfiges Aliasing die Diagrammlesbarkeit beeintr\u00e4chtigt. In \u00dcbereinstimmung mit architektonischen Richtlinien entschieden sie sich letztendlich, die konflikthafte Klasse direkt umzubenennen, wodurch langfristige Klarheit gegen\u00fcber tempor\u00e4rer Bequemlichkeit gewahrt wurde.umbenannt<\/strong>die konflikthafte Klasse direkt umzubenennen, wodurch langfristige Klarheit gegen\u00fcber tempor\u00e4rer Bequemlichkeit gewahrt wurde.<\/p>\nZur Erweiterung des Frameworks nutzte das TeamPaketzusammenf\u00fchrung (
\u00abmerge\u00bb<\/code>)<\/strong>. Dadurch konnte ein Basisinfrastrukturpaket die Inhalte eines Zielpakets \u00fcber mehrere architektonische Ebenen hinweg aufnehmen und erweitern. Anstatt strukturelle Merkmale zu duplizieren, vereinfachte die Zusammenf\u00fchrungsanweisung ein vererbungs\u00e4hnliches Verhalten auf Paketebene, wodurch der Wartungsaufwand reduziert und konsistente Baseline-Definitionen gew\u00e4hrleistet wurden.<\/p>\n
\nPhase 4: Automatisierung der Dokumentation mit PlantUML<\/h2>\n
Um Konsistenz zu gew\u00e4hrleisten und versionierte architektonische Diagramme zu erm\u00f6glichen, \u00fcbernahm das Team PlantUML als Standard f\u00fcr Diagramme als Code. Die folgenden Implementierungen wurden direkt in ihre CI\/CD-Pipeline integriert, um die automatisierte Modellvalidierung zu gew\u00e4hrleisten:<\/p>\n
Szenario A: Strukturelles Framework (Paketimport, Zugriff und Sichtbarkeit)<\/h3>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0eeab5b8ea1.png\")
<\/p>\n\n\nPlantUML<\/span>
\n
\n - \n
- \n
- \n