Entwicklung & Code
Künstliche Neuronale Netze im Überblick 5: Trainingsschleifen und Batching
Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente. Der erste Teil stellt das künstliche Neuron vor. Der fünfte Teil der Serie erstellt eine vollständige Trainingsschleife, zeigt die Unterschiede zwischen dem Training mit und ohne explizite Mini-Batches und stellt schließlich Techniken wie Dropout und Gewichtsabnahme zur Verbesserung der Generalisierung vor.
Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.
Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.
Um einem Netzwerk beizubringen, seinen Verlust zu minimieren, muss man wiederholt Daten präsentieren, Vorhersagen berechnen, Fehler messen, Gradienten propagieren und Parameter aktualisieren. Dieser Berechnungszyklus bildet die Trainingsschleife. Je nach Rechenressourcen und Problemdimensionen kann man sich dafür entscheiden, den gesamten Datensatz auf einmal, eine Probe nach der anderen oder mehrere Proben, die zu Mini-Batches gruppiert sind, zu verarbeiten.
Eine grundlegende Trainingsschleife in PyTorch beginnt mit der Definition eines Datenladers, der Batches von gelabelten (Eingabe-Ziel-) Paaren liefert, der Instanziierung eines Optimierers und einer Verlustfunktion und der anschließenden Iteration über Epochen. Nachfolgend finden Sie ein vollständiges Beispiel, das Mini-Batches verwendet. Jeder Teil des Codes wird ausführlich erklärt.
import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import DataLoader, TensorDataset
# Angenommen, wir haben einen Merkmals-Tensor X der Form (1000, 20) und einen Ziel-Tensor y der Form (1000,)
dataset = TensorDataset(X, y)
# Erstellen Sie einen DataLoader, der Batches der Größe 32 ausgibt und jede Epoche mischt
data_loader = DataLoader(dataset, batch_size=32, shuffle=True)
model = SimpleMLP(input_dim=20, hidden_dim=50, output_dim=1)
loss_fn = nn.MSELoss()
optimizer = optim.SGD(model.parameters(), lr=0.01, momentum=0.9)
num_epochs = 20
for epoch in range(num_epochs):
epoch_loss = 0.0
# Iterieren Sie über den Datensatz in Mini-Batches
for batch_inputs, batch_targets in data_loader:
# Setzen Sie die aus dem vorherigen Schritt akkumulierten Gradienten auf Null
optimizer.zero_grad()
# Berechnen Sie die Modellvorhersagen für den aktuellen Batch
batch_predictions = model(batch_inputs)
# Berechne den Verlust zwischen Vorhersagen und tatsächlichen Zielen
loss = loss_fn(batch_predictions, batch_targets)
# Backpropagation durch das Netzwerk, um Gradienten zu berechnen
loss.backward()
# Aktualisiere die Modellparameter basierend auf den Gradienten
optimizer.step()
# Akkumuliere den Verlustwert für die Berichterstellung
epoch_loss += loss.item() * batch_inputs.size(0)
# Teile durch die Gesamtzahl der Samples, um den durchschnittlichen Verlust zu erhalten
epoch_loss /= len(dataset)
print(f"Epoch {epoch+1}/{num_epochs}, Verlust: {epoch_loss:.4f}")
Der Code fasst zunächst die Merkmals- und Ziel-Tensoren in einem TensorDataset zusammen, das jede Eingabe mit der entsprechenden Beschriftung verknüpft. Anschließend erstellt er einen DataLoader, der in jeder Epoche Teilmengen der Daten in zufälliger Reihenfolge mit einer Größe von 32 ausgibt. Die Instanziierung des Modells, der Verlustfunktion und des Optimierers folgt den zuvor beschriebenen Mustern.
Die äußere Schleife verarbeitet die Daten für num_epochs vollständige Durchläufe. Innerhalb dieser Schleife initialisieren wir eine laufende Summe für den Verlust der Epoche. Jedes Mal, wenn der DataLoader einen Stapel von Eingaben und Zielen ausgibt, löscht die Anwendung alle vorherigen Gradienteninformationen, indem sie optimizer.zero_grad() aufruft. Die Berechnung von model(batch_inputs) ruft die Vorwärtsmethode des Netzwerks auf und liefert Vorhersagen. Der Code vergleicht diese Vorhersagen mit den tatsächlichen Zielen, indem er die Verlustfunktion aufruft, die einen skalaren Tensor erzeugt.
Der Aufruf von loss.backward() löst die automatische Differenziation von PyTorch aus, um die Gradienten des Verlusts in Bezug auf jeden lernbaren Parameter im Modell zu berechnen. Diese Gradienten werden im Attribut .grad jedes Parameters gespeichert. Der Aufruf von optimizer.step() ändert dann die Parameterwerte an Ort und Stelle gemäß der ausgewählten Aktualisierungsregel (in diesem Fall stochastischer Gradientenabstieg mit Momentum). Wir multiplizieren loss.item() mit der Batchgröße, um die Summe der Verluste pro Stichprobe zu ermitteln, akkumulieren diese und dividieren sie am Ende durch die Datensatzgröße, um den durchschnittlichen Verlust für die Epoche anzugeben.
Das Training ohne explizite Mini-Batches ist möglich, indem wir den gesamten Datensatz als einen Batch (Stapel) behandeln. In diesem Fall kann man den DataLoader überspringen und schreiben:
# Alle Daten als einen einzigen Batch behandeln
optimizer.zero_grad()
predictions = model(X)
loss = loss_fn(predictions, y)
loss.backward()
optimizer.step()
Dieser Full-Batch-Ansatz liefert zwar bei jedem Schritt den tatsächlichen Gradienten, kann jedoch bei großen Datensätzen ineffizient sein und mehr Speicherplatz als verfügbar erfordern. Umgekehrt kann die Verwendung von Einzelproben-Updates (stochastisch) durch Setzen von batch_size=1 im DataLoader zu einer hohen Varianz in der Gradientenschätzung führen, was zu einer verrauschten Konvergenz führt, die jedoch leichter aus flachen lokalen Minima entkommen kann. Mini-Batches stellen einen pragmatischen Kompromiss dar, indem sie die Varianz reduzieren und gleichzeitig die Speicherbeschränkungen einhalten.
Selbst wenn wir dieses Trainingsverfahren befolgen, können große neuronale Netze die Trainingsdaten überanpassen und statt Muster zu lernen, die sich auf neue Beispiele verallgemeinern lassen, zum Rauschen führen. Um die Überanpassung zu verringern, kann man Techniken für die Regularisierung anwenden.
Gewichtsabnahme, mathematisch äquivalent zur L2-Regularisierung, fügt dem Verlust eine Strafe proportional zur quadrierten Norm der Gewichte hinzu. In der Praxis signalisiert man dem Optimierer die Gewichtsabnahme. Um beispielsweise einen Koeffizienten von 1e-4 zu jedem Parameter außer den Biases hinzuzufügen, schreibt man:
optimizer = optim.SGD(
[
{'params': model.fc1.weight, 'weight_decay': 1e-4},
{'params': model.fc2.weight, 'weight_decay': 1e-4},
{'params': model.fc1.bias, 'weight_decay': 0},
{'params': model.fc2.bias, 'weight_decay': 0}
],
lr=0.01,
momentum=0.9
)
Durch die Angabe von weight_decay für jede Parametergruppe fügt der Optimierer weight_decay * θ zum Gradienten jedes Gewichts hinzu und führt so effektiv die Aktualisierungsregel
θ ← θ − η ( ∂L/∂θ + λ · θ )
für jedes Gewicht θ aus, wobei λ der Gewichtsabklingkoeffizient ist.
Eine weitere leistungsstarke Regularisierungstechnik ist Dropout. Während des Trainings setzt Dropout bei jedem Vorwärtsdurchlauf zufällig einen Bruchteil p der Aktivierungen jeder Schicht auf Null, wodurch eine gegenseitige Anpassung der Neuronen verhindert wird. Zum Testzeitpunkt erfolgt die Deaktivierung von Dropout und die Skalierung der Aktivierungen um (1–p), um sie an die erwartete Größe anzupassen. In PyTorch fügt man Dropout-Schichten in die Modelldefinition ein. Um beispielsweise Dropout nach der ersten versteckten Schicht hinzuzufügen:
import torch.nn as nn
class MLPWithDropout(nn.Module):
def __init__(self, input_dim, hidden_dim, output_dim, p=0.5):
super().__init__()
self.fc1 = nn.Linear(input_dim, hidden_dim)
self.dropout = nn.Dropout(p=p)
self.relu = nn.ReLU()
self.fc2 = nn.Linear(hidden_dim, output_dim)
def forward(self, x):
x = self.fc1(x)
x = self.relu(x)
# Randomly zero a fraction p of elements during training
x = self.dropout(x)
x = self.fc2(x)
return x
Wenn sich das Modell im Trainingsmodus befindet – was sich durch den Aufruf von model.train() sicherstellen lässt –, erfolgt bei jedem Vorwärtsdurchlauf die Auswahl einer neuen zufälligen Binärmaske, die einen Bruchteil p der Elemente in der versteckten Darstellung auf Null setzt. Durch den Aufruf von model.eval() vor dem Auswerten der Validierungsdaten lässt sich Dropout deaktivieren und der gesamte Satz von Aktivierungen verwenden.
Über den Gewichtsabbau und Dropout hinaus kann Early Stopping vor Overfitting schützen, indem die Leistung anhand eines Holdout-Validierungssatzes überwacht und das Training abgebrochen wird, wenn sich der Validierungsverlust nicht mehr verbessert. In der Regel speichert man die Modellparameter, wenn der Validierungsverlust abnimmt, und beendet das Training, wenn über eine bestimmte Anzahl von Epochen keine Verbesserung mehr auftritt.
Mit diesen Regularisierungsstrategien kann man tiefere und breitere Netzwerke trainieren und gleichzeitig eine robuste Generalisierung aufrechterhalten. Im nächsten Kapitel werden wir auf dieser Grundlage aufbauen und konvolutionale neuronale Netzwerke, rekurrenten Netzwerke und hybride Architekturen untersuchen, die mehrere Schichttypen kombinieren.
(rme)
Entwicklung & Code
Stack Overflow: Kuratierte Knowledge Base für KI-Agenten im Unternehmen
Das Entwicklerforum Stack Overflow stellt ein Knowledge-Base-Tool für Unternehmen vor. Es verbindet kuratiertes Wissen mit KI-Unterstützung und Microsoft-365-Anbindung. So soll es als zuverlässiger Informations-Pool im Unternehmen dienen.
Weiterlesen nach der Anzeige
Stack Internal soll das verteilte Wissen im Unternehmen in einer einheitlichen, von Menschen geprüften Basis zusammenführen, die den Qualitätsansprüchen und Compliance-Regeln der Firma entspricht. KI kommt beim Zusammenstellen der Informationen aus Quellen wie Confluence oder Teams zum Einsatz. Die Maschine klassifiziert die Daten beim Einlesen und präsentiert sie den menschlichen Prüferinnen und Prüfern in sortierter und vorbewerteter Form. Die Kuratoren korrigieren die Vorschläge und geben sie frei.
Enge Verknüpfung mit Microsoft 365
Die Inhalte von Stack Internal dienen einerseits als Basis für den KI-Chat in Microsoft-Tools, also Office 365, Teams und dem Coding-Copiloten für Entwicklerinnen und Entwickler. Ein MCP-Server ermöglicht andererseits die Anbindung an weitere GenAI-Modelle und Agenten. Umgekehrt sollen Interaktionen mit der Knowledge Base das Wissen darin verbessern und erweitern. Auf welche Art das geschehen soll, erklärt der Anbieter nicht.
Stack Internal ist eine Weiterentwicklung von Stack Overflow for Teams und läuft auf Azure. Es gibt Cloud- und On-Premises-Varianten, darunter eine kostenlose für bis zu fünfzig Mitglieder.
Stack Overflow macht mit Stack Internal aus der Not eine Tugend: Gestartet als Forum für Entwicklerinnen und Entwickler, war Stack Overflow mit der Verbreitung von Coding-Assistenten zu einer reinen Trainingsfundgrube für KI-Modelle abgesunken. Dass solide Trainingsdaten aber einen Wert eigener Art darstellen, vermarktet der Anbieter Stack Exchange nun.
(who)
Entwicklung & Code
Kommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
Ein neues, kostenloses Git-Management-Tool vereinfacht die Arbeit mit der Versionierungssoftware Git. Viele Funktionen lassen sich zusammenfassen oder schnell und übersichtlich ausführen, auch in älteren Commits. Dabei verwaltet es mehrere lokale Repositories gleichzeitig.
Weiterlesen nach der Anzeige
Anbieter RemObjects schreibt im Blog, dass das macOS-Tool GitBrowser die Alltagsaufgaben von Entwicklerinnen und Entwicklern beim Versionsmanagement beschleunigen soll. Das Fenster des Tools ist dreigeteilt: In der linken Sidebar findet sich eine Liste der Repos, die sich gruppieren und umbenennen lassen. Entwickler führen hier Aktionen über das Kontextmenü aus – auch in nicht aktiven Projekten.
Der Mittelteil zeigt die Versionen eines Repos, und zwar noch zu pushende in Fett, noch zu pullende kursiv und noch zu mergende blau. Auch die verschiedenen Autoren sind farblich unterschiedlich gekennzeichnet. Rechts im Fenster finden sich die betroffenen Dateien eines Commits und darunter eine Diff-Ansicht. Bei Doppelklick auf einen Commit öffnet sich ein Diff-Tool des Anwenders, derzeit Araxis Merge oder BBEdit. Weitere sollen laut Anbieter hinzukommen.
Ganz oben im Fenster steht der lokale Status, beim Klick darauf öffnet sich rechts die Bühne mit Checkboxen zum Hinzufügen oder Entfernen von Dateien. Darunter steht ein dreifach Diff: eine originale, lokale und auf der Stage liegende Variante.
Commiten und Pushen lässt sich mit einem Klick, und die Commit-Nachricht lässt sich auf Wunsch bereits beim Stagen von einer KI erzeugen. Möglich sind hier OpenAI, Claude, Gemini, Grok, Mistral oder eine lokale Verknüpfung mit LM Studio. Wer selbst die Nachricht schreibt, kann mit Pfeiltasten in älteren Ausgaben blättern.
Pullen lassen sich alle Repos auf einen Schlag oder alle einer Gruppe. Anwender ziehen Dateien, auch aus älteren Commits, per Drag-and-drop in andere Tools – ohne Checkout – GitBrowser extrahiert sie automatisch. Der Wechsel zwischen Zweigen erfolgt einfach über einen Popup-Button.
Der Anbieter betont im Blog, dass GitBrowser nicht für tiefergehende Funktionen gedacht sei, sondern alltägliche Verwaltungsvorgänge erleichtern soll. Anspruchsvolle Anwenderinnen und Anwender werden ganz ohne Kommandozeile also doch nicht auskommen.
Weiterlesen nach der Anzeige
Lesen Sie auch
(who)
Entwicklung & Code
Clean Architecture und Co.: Softwarearchitektur mit Mustern strukturieren
Strukturierte Software basiert auf einem Plan, der die spezifischen Anforderungen an ein System berücksichtigt und in lose gekoppelte Bausteine überführt. In der arbeitsteiligen Softwareentwicklung benötigen Entwicklungsteams solche gemeinsamen Pläne, um eine harmonische und einheitliche Architektur zu entwickeln, ohne jedes Detail vorab miteinander abstimmen zu müssen. Bewähren sich die Pläne, entwickeln sich daraus Muster und Prinzipien auf unterschiedlichen Architekturebenen.
Weiterlesen nach der Anzeige
Matthias Eschhold ist Lead-Architekt der E-Mobilität bei der EnBW AG. Als Experte für Domain-driven Design gestaltet er die IT-Landschaft und Team-Topologien der E-Mobilität. Trotz strategischer Schwerpunkte bleibt er mit Java und Spring Boot nah am Code, entwickelt Prototypen und führt Refactorings durch. Als Trainer vermittelt er seit Jahren praxisnahe Softwarearchitektur, die Theorie und Projektrealität verbindet.
Bei der grundlegenden Strukturierung eines Systems muss man zwischen Architekturstilen und Architekturmustern unterscheiden, wobei sie sich nicht immer sauber abgrenzen. Ein Architekturstil ist ein Mittel, das dem System eine grundlegende Struktur verleiht. Beim Stil Event-driven Architecture basiert die Anwendung beispielsweise auf asynchroner Kommunikation, und Events beeinflussen die Architektur und den Code an vielen Stellen. Gleiches gilt für REST, das eine ressourcenorientierte Struktur vorgibt.
Entscheidet sich ein Entwicklungsteam für Microservices als Architekturstil, wählt es eine verteilte Systemarchitektur, beim Stil Modularer Monolith ist das Gegenteil der Fall. In komplexen Systemen kombinieren Architektinnen und Architekten in der Regel mehrere Stile. Manche Architekturstile ergänzen sich, etwa REST und Microservices, während sich andere gegenseitig ausschließen, wie Microservices und der Modulare Monolith.
Ob Microservices oder Modularer Monolith – beides sagt wenig über die Gestaltung der internen Strukturen aus. Auf dieser inneren Architekturebene, der Anwendungsarchitektur, kommen Muster zum Einsatz, die Entwurfsprinzipien und -regeln kombinieren und eine Basisstruktur der Anwendung prägen. Architekturmuster der Anwendungsarchitektur nutzen Verantwortungsbereiche und Beziehungsregeln als Strukturierungsmittel. Im Muster Clean Architecture sind dies beispielsweise konzentrische Ringe, wobei die Beziehungsrichtung stets zum inneren Kern des Ringmodells führt. Die geschichtete Architektur (Layered Architecture) hingegen unterteilt die Verantwortungsbereiche in hierarchische Schichten, wobei jede Schicht nur mit der darunter liegenden kommunizieren darf (siehe Abbildung 1).
Vergleich zwischen Clean Architecture und Schichtenarchitektur (Abb. 1).
Mustersprache als Fundament
Eine Mustersprache ergänzt Architekturmuster für einen ganzheitlichen Konstruktionsplan – von Modulen und Paketen bis hin zum Klassendesign. Sie bildet das Fundament für eine konsistente und verständliche Umsetzung der Muster und beschreibt eine Reihe von Entwurfsmustern für die Programmierung auf der Klassenebene.
Weiterlesen nach der Anzeige
Die Klassen der Mustersprache bilden Geschäftsobjekte, Fachlogik und technische Komponenten ab. Sie werden unter Einhaltung der definierten Beziehungsregeln in einem Klassenverbund implementiert. Diese Regeln bestimmen, wie die Klassen miteinander interagieren, wie sie voneinander abhängen und welche Aufgaben sie haben. Ein Geschäftsobjekt ist charakterisiert durch seine Eigenschaften und sein Verhalten, während ein Service Geschäftslogik und fachliche Ablaufsteuerung implementiert. Eine derartige, genaue Differenzierung gestaltet Architektur klar und nachvollziehbar.
Ein wichtiger Aspekt einer Mustersprache ist die Organisation des Codes in einer gut verständlichen Hierarchie. Dadurch fördert sie die Verteilung von Verantwortlichkeiten auf unterschiedliche Klassen. Prinzipiell kann jedes Projekt seine eigene Mustersprache definieren oder eine bestehende als Basis verwenden und mit individuellen Anforderungen ausbauen. Eine Mustersprache sorgt auch im Team dafür, dass alle Mitglieder dieselben Begriffe und Prinzipien verwenden.
Dieser Artikel wählt die DDD Building Blocks als Grundlage für eine Mustersprache, wie die folgende Tabelle und Abbildung 2 zeigen.
| Value Object | Ein Value Object repräsentiert einen unveränderlichen Fachwert ohne eigene Entität. Das Value Object ist verantwortlich für die Validierung des fachlichen Werts und sollte nur in einem validen Zustand erzeugt werden können. Ferner implementiert ein Value Object dazugehörige Fachlogik. |
| Entity | Eine Entity ist ein Objekt mit einer eindeutigen Identität und einem Lebenszyklus. Die Entität wird beschrieben durch Value Objects und ist verantwortlich für die Validierung fachwertübergreifender Geschäftsregeln sowie die Implementierung dazugehöriger Fachlogik. |
| Aggregate | Ein Aggregate ist eine Sammlung von Entitäten und Value Objects, die durch eine Root Entity (oder Aggregate Root bzw. vereinfacht Aggregate) zusammengehalten werden. Die Root Entity definiert eine fachliche Konsistenzgrenze, klar abgegrenzt zu anderen Root Entities (oder Aggregates). |
| Domain Service | Ein Domain Service implementiert Geschäftslogik, die nicht zu einer Entität oder einem Value Object gehört. Weiter steuert der Domain Service den Ablauf eines Anwendungsfalls. Ein Domain Service ist zustandslos zu implementieren. |
| Factory | Eine Factory ist für die Erstellung von Aggregates, Entitäten oder Value Objects verantwortlich. Die Factory kapselt die Erstellungslogik komplexer Domänenobjekte. |
| Repository | Ein Repository ist verantwortlich für die Speicherung und das Abrufen von Aggregaten und Entitäten aus einer Datenquelle. Das Repository kapselt den Zugriff auf eine Datenbank oder auch andere technische Komponenten. |
Mustersprache des taktischen Domain-driven Design (Abb. 2).
Ein Beispiel verdeutlicht den Unterschied zwischen einem Value Object und einer Entity: Eine Entity könnte ein bestimmtes Elektrofahrzeug sein. Entities sind also eindeutig und unverwechselbar. In der realen Welt zeigt sich das an der global eindeutigen Fahrgestellnummer (VIN). Der aktuelle Zustand eines E-Fahrzeugs wird zu einem bestimmten Zeitpunkt beispielsweise durch seinen Ladezustand beschrieben, ein Wert, der sich im Laufe der Nutzung des Fahrzeugs verändert. Der Ladezustand entspricht einem Value Object. Er verfügt über keine eigene Identität, sondern definiert sich ausschließlich durch seinen Wert.
Erweiterung der Mustersprache auf Basis der Stile und Muster
Die Mustersprache der Building Blocks ist nicht vollständig. Sie benötigt weitere Elemente, die von den eingesetzten Architekturstilen und -mustern abhängen. REST als Architekturstil führt beispielsweise zwei Elemente in die Mustersprache ein: Controller und Resource. Bei der Integration von REST als Provider liegt der Fokus auf der Resource, die als Datentransferobjekt (DTO) über den API-Endpunkt bereitsteht. Der Controller fungiert als Schnittstelle zwischen der Anfrage des Konsumenten und der Fachlogik des Systems. Das heißt, der Controller nutzt den bereits eingeführten Domain Service und delegiert die Ausführung von Fachlogik an diesen.
Bei der Integration von REST als Consumer erhält die Mustersprache das Element Service Client, das dem Abrufen von Daten oder Ausführen von Funktionen über einen externen API-Endpunkt dient. Der Domain Service triggert dies als Teil der Fachlogik über den Service Client.
Der Stil Event-driven Architecture erweitert die Mustersprache um die Elemente Event Listener, Event Publisher und das Event selbst. Ein Event Listener hört auf Ereignisse und ruft den entsprechenden Domain Service auf, um die Ausführung der Geschäftslogik auszulösen. Der Event Publisher veröffentlicht eine Zustandsveränderung in der Fachlichkeit über ein Event. Der Domain Service triggert die Event-Veröffentlichung als Teil seiner Fachlogik und nutzt hierfür den Event Publisher.
Die in diesen Beispielen aufgeführten Begriffe sind im Vergleich zu den DDD Building Blocks nicht in der Literatur definiert und entstammen der Praxis. Abbildung 3 zeigt die Klassen der erweiterten Mustersprache.
Elemente der Mustersprache des taktischen Domain-driven Design (Abb. 3).
Architekturmuster kombinieren Regeln, Entwurfsmuster und Prinzipien. Muster wie Clean Architecture, die sich besonders für komplexe Systeme mit hohen Anforderungen an den Lebenszyklus eignen, bündeln mehrere Konzepte und beeinflussen daher die Mustersprache stärker als andere Muster. Ein Beispiel ist das Konzept Use Case in der Clean Architecture, das ein zentrales Element darstellt und die Mustersprache um die Elemente Use Case Input Port, Use Case Output Port und Use Case Interactor erweitert. Ein weiteres Beispiel ist die Anwendung des Dependency Inversion Principle (DIP) in der Clean Architecture, das zu dem Musterelement Mapper führt.
Nach dem Exkurs über die Mustersprachen stellt dieser Artikel verschiedene Architekturmuster vor, die sich in schichten- und domänenbasierende unterteilen.
Schichtenbasierende Architekturmuster
Schichtenbasierende Architekturmuster sind datenzentrisch strukturiert. Je nach Muster ist dieser Aspekt mehr oder weniger ausgeprägt. Die Schichtung unterscheidet sich in technischer (horizontal geschnitten) und fachlicher (vertikal geschnitten) Hinsicht. Für die weitere Beschreibung eignet sich die Begriffswelt von Simon Brown mit „Package by …“ .
Package by Layer: Dieses Muster organisiert die Anwendung nach technischen Aspekten, zum Beispiel nach Controller, Service und Repository (Abbildung 4). Es kommt jedoch schnell an seine Grenzen: Mittlere und große Systeme mit komplizierter Fachlichkeit erfordern eine vertikale Schichtung anhand fachlicher Aspekte, andernfalls enden die Projekte erfahrungsgemäß in komplizierten Monolithen mit vielen Architekturverletzungen.
Vorteile:
- Bekannt und verbreitet
- Einfach zu verstehen und anzuwenden
- In kleinen Projekten praktikabel
Nachteile:
- Enge Kopplung zwischen Schichten, mit der Gefahr chaotischer Abhängigkeiten bei Wachstum des Systems
- Fachlich zusammenhängende Funktionalitäten sind über viele Pakete verteilt
- Schwer wartbar und erweiterbar bei mittleren bis großen Anwendungen
Das Architekturmuster Package by Layer (Abb. 4).
Package by Feature: Der Code organisiert sich vertikal anhand fachlicher Aspekte. Eine Schnitt-Heuristik, wie genau das Feature von den fachlichen Anforderungen abzuleiten ist, definiert das Architekturmuster nicht. Es definiert nur, dass dieser fachliche Schnitt zu erfolgen hat. Wird das taktische DDD angewendet, erfolgt der Schnitt entlang der Aggregates (siehe Abbildung 5).
Vorteile:
- Fachlich kohäsiver Code ist lokal zusammengefasst, was zu hoher Wartbarkeit und Erweiterbarkeit führt.
- Modularisierung ermöglicht die unabhängige Entwicklung fachlicher Module.
- Fachliche Ende-zu-Ende-Komponenten sind lose gekoppelt.
- Abhängigkeiten zwischen fachlichen Modulen müssen explizit gehandhabt werden, was die Robustheit der Architektur gegenüber ungewünschten Abhängigkeiten erhöht.
- Fachlich komplexe, mittelgroße bis große Anwendungen lassen sich mit vertikalen Schichten besser beherrschen als mit Package by Layer und Package by Component.
Nachteile:
- Abhängigkeiten zwischen fachlichen Modulen erfordern fortgeschrittene Kommunikationsmuster (zum Beispiel Events), was die architektonische Komplexität erhöht.
- Vertikale Modularisierung muss gut durchdacht werden, um enge Kopplung zwischen Modulen zu vermeiden.
Das Architekturmuster Package by Feature (Abb. 5).
Package by Component: Das Muster strukturiert die Anwendung sowohl fachlich (vertikal) als auch technisch (horizontal), wobei sich ein fachliches Feature in eine Inbound-Komponente und eine Domain-Komponente aufteilt (siehe Abbildung 6). Die Domain-Komponente kapselt Geschäftslogik und die dazugehörige Persistenzschicht. Diese Unterteilung in fachliche Module ist ein entscheidender Unterschied zu Package by Layer.
Vorteile:
- Gute Modularisierung durch fachliche Grenzen zwischen Komponenten
- Hohe Wiederverwendbarkeit der Domain-Komponenten, durch unterschiedliche Inbound-Komponenten
- Erleichterte Testbarkeit durch gesteigerte Modularisierung im Vergleich zu Package by Layer
Nachteile:
- Enge Kopplung zwischen Inbound- und Domain-Schicht, mit dem Risiko indirekter Abhängigkeiten und Seiteneffekten bei Änderungen, insbesondere wenn die Anwendung wächst
- Komponentenkommunikation schwer beherrschbar bei erhöhter fachlicher Komplexität
- Schwerer erweiterbar für mittlere bis große Anwendungen mit höherer fachlicher Komplexität
Das Architekturmuster in Package by Component (Abb. 6).
-
UX/UI & Webdesignvor 3 MonatenAdobe Firefly Boards › PAGE online
-
Apps & Mobile Entwicklungvor 3 MonatenGalaxy Tab S10 Lite: Günstiger Einstieg in Samsungs Premium-Tablets
-
UX/UI & Webdesignvor 1 MonatIllustrierte Reise nach New York City › PAGE online
-
Datenschutz & Sicherheitvor 3 MonatenHarte Zeiten für den demokratischen Rechtsstaat
-
Datenschutz & Sicherheitvor 2 MonatenJetzt patchen! Erneut Attacken auf SonicWall-Firewalls beobachtet
-
Online Marketing & SEOvor 3 Monaten„Buongiorno Brad“: Warum Brad Pitt für seinen Werbejob bei De’Longhi Italienisch büffeln muss
-
Online Marketing & SEOvor 3 MonatenCreator und Communities: Das plant der neue Threads-Chef
-
Entwicklung & Codevor 3 MonatenPosit stellt Positron vor: Neue IDE für Data Science mit Python und R