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.

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.

(who)

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.

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).

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.

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.

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.

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

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.

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

Heute erzähle ich von einem typischen Arbeitstag als Softwarearchitekt, der schon vor dem Weg zur Arbeit beginnt.

6:30 Uhr – Der Beginn der architektonischen Erleuchtung

Der Wecker schreit mit der Begeisterung eines Junior-Entwicklers, der gerade Designmuster entdeckt hat. Als Softwarearchitekt beginnt mein Tag nicht mit Kaffee, sondern mit einem kurzen Blick auf die Produktionswarnungen der letzten Nacht. Drei kritische Systeme sind ausgefallen, zwei Datenbanken laufen aus unerfindlichen Gründen so, als würden sie auf einem Server aus dem Jahr 1995 mit einem antiken Prozessor laufen, und es gibt eine dringende Slack-Nachricht von jemandem, der fragt, ob wir „einfach schnell Blockchain zu unserem Warenkorb hinzufügen können, weil der CEO gehört hat, dass das revolutionär ist“.

Ich schenke mir eine Tasse Kaffee ein, der so stark ist, dass er wahrscheinlich selbst Code kompilieren könnte, und bereite mich mental auf einen weiteren Tag vor, an dem ich Geschäftsträume in technische Realität umsetzen und mich dabei durch die tückischen Gewässer der Unternehmensbürokratie navigieren muss.

7:45 Uhr – Der Weg zur Arbeit: Wo Architekturträume sterben

Während meiner Fahrt zur Arbeit erhalte ich den ersten von insgesamt siebzehn Anrufen, die ich heute erhalten werde. Er kommt vom Projektmanager, der entdeckt hat, dass unsere sorgfältig geplante Microservices-Architektur möglicherweise mehrere Dienste erfordert. Der Horror! Ich verbringe zwanzig Minuten damit, zu erklären, warum „einfach einen großen Dienst daraus zu machen“ den Zweck der letzten Sechs-Monats-Planung zunichtemacht. Dieses Gespräch wird sich heute noch viermal mit verschiedenen Personen wiederholen, die offenbar an derselben Besprechung teilgenommen haben, aber völlig unterschiedliche Dinge gehört haben wollen.