Connect with us

Entwicklung & Code

Die stille Epidemie: Von großen Sprachmodellen zu digitalen Dealern


In den schummrigen Ecken moderner Softwareentwicklungsbüros breitet sich still und leise eine neue Art der Sucht aus. Dabei geht es nicht um Substanzen oder traditionelle Laster, sondern um eine schleichende Abhängigkeit von künstlicher Intelligenz, die verspricht, jedes Programmierproblem mit einem einfachen Druck auf die Eingabetaste zu lösen. Große Sprachmodelle sind für Softwareentwickler zum digitalen Äquivalent einer leistungssteigernden Droge geworden, die sofortige Befriedigung und scheinbar unbegrenztes Wissen bieten, allerdings auf Kosten von etwas, das weitaus wertvoller ist, als wir zunächst gedacht haben.

Weiterlesen nach der Anzeige


Michael Stal

Michael Stal

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.

Das Phänomen beginnt harmlos genug. Ein Softwareentwickler stößt auf eine besonders schwierige Algorithmusimplementierung und beschließt, ein LLM um Rat zu fragen. Die Antwort kommt innerhalb von Sekunden, komplett mit funktionierendem Code, detaillierten Erklärungen und sogar Optimierungsvorschlägen. Der Dopamin-Kick wirkt sofort und stark. Was Stunden der Recherche, des Ausprobierens und des intensiven Nachdenkens gekostet hätte, ist zu einem kurzen Gespräch mit einem künstlichen Assistenten komprimiert. Der Entwickler fühlt sich produktiv, effizient und bemerkenswert kompetent.

Diese erste Erfahrung schafft einen starken psychologischen Präzedenzfall. Das Gehirn, das immer den Weg des geringsten Widerstands sucht, beginnt, Problemlösungen eher mit der Konsultation eines LLM als mit unabhängiger Analyse in Verbindung zu bringen. Was als gelegentliche Unterstützung beginnt, verwandelt sich allmählich in eine primäre Problemlösungsstrategie. Der Entwickler greift zur LLM-Schnittstelle, bevor er überhaupt versucht, Herausforderungen selbstständig zu durchdenken.

Das Suchtpotenzial von LLMs wirkt über dieselben neurologischen Bahnen, die auch andere Formen der Verhaltenssucht steuern. Jede erfolgreiche Interaktion mit einem KI-System löst die Ausschüttung von Dopamin im Belohnungszentrum des Gehirns aus und schafft so eine starke Verbindung zwischen Problemlösung und externer Unterstützung. Im Gegensatz zum traditionellen Lernen, das mit verzögerter Befriedigung und allmählichem Aufbau von Fähigkeiten verbunden ist, bieten LLM-Interaktionen sofortige Belohnungen, die die natürlichen Lernmechanismen des Gehirns hijacken können.

Neurowissenschaftliche Untersuchungen haben gezeigt, dass die Erwartung einer Belohnung oft stärkere Dopaminreaktionen hervorruft als die Belohnung selbst. Dies erklärt, warum Entwicklerinnen oft einen Adrenalinstoß verspüren, wenn sie eine Anfrage für ein LLM formulieren, noch bevor sie die Antwort erhalten. Das Gehirn beginnt, sich nach diesem Zustand der Vorfreude zu sehnen, was zu einer erhöhten Häufigkeit der KI-Konsultation führt, selbst bei Problemen, die sich mit minimalem Aufwand selbstständig lösen lassen.

Weiterlesen nach der Anzeige

Der variable Verstärkungsplan, der den LLM-Interaktionen innewohnt, schafft ein besonders starkes Suchtpotenzial. Manchmal liefert die KI sofort perfekte Lösungen, manchmal sind mehrere Iterationen und Verfeinerungen erforderlich, und gelegentlich liefert sie Antworten, die erhebliche Modifikationen benötigen oder sich als gänzlich unbrauchbar erweisen. Diese Unvorhersehbarkeit spiegelt die psychologischen Mechanismen wider, die beim Glücksspiel süchtig machen, und erzeugt ein zwanghaftes Bedürfnis, „noch eine weitere Eingabe zu versuchen“, um die perfekte Antwort zu erhalten.

Betrachten wir den Fall eines erfahrenen Entwicklers, der an einem komplexen Problem zur Optimierung einer Datenstruktur arbeitet. In der Zeit vor LLM wäre er die Herausforderung angegangen, indem er zunächst die zugrunde liegenden Datenmuster verstanden, bestehende Algorithmen recherchiert, mögliche Lösungen skizziert und seinen Ansatz durch Experimente iterativ verfeinert hätte. Dieser Prozess wäre zwar zeitaufwendig gewesen, hätte aber sein Verständnis für algorithmische Komplexität, Kompromisse bei Datenstrukturen und Optimierungsprinzipien vertieft.

Mit der sofort verfügbaren LLM-Unterstützung beschreibt derselbe Entwickler nun sein Problem dem KI-System und erhält innerhalb weniger Minuten eine ausgeklügelte Lösung. Der Code funktioniert, die Leistungskennzahlen verbessern sich und das Projekt schreitet voran. Allerdings hat der Entwickler den entscheidenden Lernprozess umgangen, der sein grundlegendes Verständnis des Problemfeldes verbessert hätte. Er ist eher ein Konsument von Lösungen geworden als ein Schöpfer von Verständnis.

LLM-Sucht manifestiert sich in verschiedenen Formen, die jeweils unterschiedliche Merkmale und Verlaufsmuster aufweisen. Der Query Junkie stellt die offensichtlichste Form der Abhängigkeit dar, die durch zwanghaftes Prompting-Verhalten und die Unfähigkeit gekennzeichnet ist, Probleme ohne sofortige KI-Konsultation anzugehen. Diese Menschen halten oft mehrere LLM-Schnittstellen gleichzeitig offen und verspüren echte Angst, wenn sie gezwungen sind, ohne KI-Unterstützung zu arbeiten.

Der Solution Collector ist eine subtilere Form der Abhängigkeit, bei der man riesige Bibliotheken mit KI-generierten Code-Schnipseln und Lösungen ansammelt, ohne ein tiefes Verständnis für die zugrunde liegenden Prinzipien zu entwickeln. Solution Collectors sind sehr effizient darin, bestehende Lösungen zu finden und anzupassen, verlieren jedoch die Fähigkeit, neue Ansätze zu entwickeln oder die grundlegenden Kompromisse zu verstehen, die mit ihrer Umsetzung verbunden sind.

Das Suchtmuster des Pseudo-Experten ist besonders gefährlich, da es eine Illusion von Kompetenz erzeugt, während es tatsächlich echtes Fachwissen untergräbt. Die vermeintlichen Experten verstehen sich geschickt darin, anspruchsvolle Fragen zu stellen und KI-Antworten zu interpretieren, was sie zu der Annahme verleitet, dass sie über tiefgreifendes Wissen verfügen, obwohl sie tatsächlich nur ein oberflächliches Verständnis haben. Sie können komplexe Themen mithilfe von KI-basierten Erkenntnissen flüssig diskutieren, haben jedoch Schwierigkeiten, wenn sie eine Komponente mit neuen Problemen konfrontiert, die echte Kreativität oder tiefgreifende Analysen erfordern.

Der Validierungssuchende nutzt LLMs nicht in erster Linie zur Lösungsfindung, sondern zur ständigen Bestätigung seiner eigenen Ideen und Ansätze. Das mag zwar weniger problematisch erscheinen als eine vollständige Abhängigkeit von KI-Lösungen, untergräbt jedoch das Selbstvertrauen und das unabhängige Urteilsvermögen. Diese Menschen verlieren allmählich das Vertrauen in ihre eigenen analytischen Fähigkeiten und sind ohne die Bestätigung durch KI nicht mehr in der Lage, technische Entscheidungen zu treffen.

Die Sucht manifestiert sich auf immer subtilere Weise. Entwicklerinnen und Entwickler verspüren Angst, wenn sie gezwungen sind, ohne LLM-Zugang zu arbeiten, ähnlich wie das Unbehagen, das man empfindet, wenn man von seinem Smartphone getrennt ist. Sie entwickeln eine sogenannte Prompt-Abhängigkeit, bei der ihr Problemlösungsprozess vollständig auf die Formulierung von Anfragen für KI-Systeme ausgerichtet ist, anstatt sich mit einer unabhängigen Analyse zu befassen.

Die psychologischen Mechanismen, die dieser Abhängigkeit zugrunde liegen, spiegeln diejenigen wider, die auch bei anderen Formen der digitalen Sucht zu finden sind. Das variable Belohnungssystem von LLMs erzeugt einen starken Konditionierungseffekt. Manchmal liefert die KI sofort genau die richtige Lösung, manchmal sind Verfeinerungen und Iterationen erforderlich, und gelegentlich gibt sie Antworten, die erhebliche Modifikationen benötigen. Diese Unvorhersehbarkeit erzeugt die gleichen psychologischen Reize, die soziale Medien und Gaming-Plattformen so attraktiv machen.

Das Konzept des Flow-Zustands, das Softwareentwickler seit langem als Höhepunkt produktiver Programmiererfahrung schätzen, lässt sich für diejenigen, die auf die Unterstützung von LLMs angewiesen sind, immer schwerer erreichen. Flow erfordert eine intensive Auseinandersetzung mit herausfordernden Problemen, anhaltende Konzentration und den schrittweisen Aufbau von Verständnis durch beharrliche Anstrengungen. Die Abhängigkeit von LLMs stört diesen Prozess, indem sie externe Lösungen liefert, bevor der Entwickler die Möglichkeit hatte, sich intensiv mit dem Problemfeld auseinanderzusetzen.

Die Verschlechterung der Debugging-Fähigkeiten ist einer der besorgniserregendsten Aspekte der LLM-Abhängigkeit. Debugging diente traditionell als wichtiger Lernmechanismus in der Softwareentwicklung und zwang Developer dazu, das Systemverhalten zu verstehen, Ausführungspfade zu verfolgen und mentale Modelle der Programmfunktion zu entwickeln. Entwickler, die Debugging-Aufgaben an KI-Systeme delegieren, verpassen diese Lernmöglichkeiten und verlieren nach und nach die analytischen Fähigkeiten, die für die Diagnose komplexer Probleme erforderlich sind.

Dieses Phänomen geht über den Verlust individueller Fähigkeiten hinaus und wirkt sich auch auf grundlegende kognitive Prozesse aus. Developer, die von LLM-Unterstützung abhängig sind, erleben oft das, was Kognitionswissenschaftler als kognitive Entlastung bezeichnen, wobei externe Tools so sehr zu einem integralen Bestandteil des Denkprozesses verkommen, dass sich unabhängiges Denken als schwierig oder unmöglich erweist. Dies ähnelt der Art und Weise, wie die Abhängigkeit von GPS die räumlichen Navigationsfähigkeiten beeinträchtigen kann, aber die Auswirkungen auf die Softwareentwicklung sind weitaus tiefgreifender.

Die Gedächtniskonsolidierung, ein entscheidender Aspekt der Kompetenzentwicklung, zeigt sich beeinträchtigt, wenn Entwickler sich stark auf externe KI-Unterstützung verlassen. Der Prozess des Ringens mit Problemen, des Machens von Fehlern und des allmählichen Aufbaus von Verständnis schafft starke neuronale Bahnen, die eine schnelle Mustererkennung und intuitive Problemlösung ermöglichen. Die Abhängigkeit von LLM unterbricht diesen Prozess und führt zu Wissen, das sich umfassend anfühlt, aber nicht die für eine fachkundige Leistung erforderliche tiefe Integration aufweist.

Eine besonders besorgniserregende Ausprägung der LLM-Abhängigkeit ist die allmähliche Erosion der Debugging-Fähigkeiten. Debugging ist traditionell eine der wertvollsten Kompetenzen, die Developer entwickeln können, da es systematisches Denken, die Bildung von Hypothesen und methodisches Untersuchen erfordert. Wer von LLM-Unterstützung abhängig ist, beginnt oft damit, Debugging-Aufgaben an KI-Systeme zu delegieren und Fehlermeldungen und Symptome zu beschreiben, anstatt die analytischen Fähigkeiten zu entwickeln, die notwendig sind, um Probleme bis zu ihren Ursachen zurückzuverfolgen.

Die Auswirkungen der LLM-Abhängigkeit variieren erheblich zwischen den verschiedenen Spezialisierungen der Softwareentwicklung, die jeweils einzigartige Herausforderungen und Risiken mit sich bringen. Frontend-Entwickler könnten feststellen, dass ihre Designkompetenz nachlässt, da sie sich zunehmend auf KI-generierte Benutzeroberflächenkomponenten und Styling-Lösungen verlassen. Das subtile Verständnis der Prinzipien der Benutzererfahrung, der visuellen Hierarchie und des Interaktionsdesigns, das Entwickler durch praktische Experimente erwerben, ersetzen LLMs durch algorithmische Vorschläge, die zwar technisch kompetent sind, aber keine menschliche Einsicht bieten.

Backend-Entwicklerinnen stehen vor anderen Herausforderungen, insbesondere in Bereichen, die ein tiefes Verständnis der Systemarchitektur und der Leistungsmerkmale erfordern. LLM-generierte Lösungen funktionieren oft gut für gängige Szenarien, können jedoch subtile Ineffizienzen oder architektonische Entscheidungen enthalten, die bei großem Umfang problematisch sind. Entwickler, die sich stark auf KI-Unterstützung verlassen, übersehen möglicherweise diese Nuancen, was zu Systemen führt, die anfangs gut funktionieren, aber mit zunehmender Komplexität oder Benutzerlast auf ernsthafte Probleme stoßen.

Datenbankspezialisten sind besonders gefährdet, da die Datenbankoptimierung ein tiefes Verständnis von Abfrageausführungsplänen, Indexstrategien und Datenverteilungsmustern erfordert. Diese Erkenntnisse entwickeln sich durch jahrelange praktische Erfahrung mit realen Leistungsproblemen. Von LLM generierte Datenbanklösungen folgen oft Standardmustern, übersehen jedoch möglicherweise die subtilen Optimierungen, die Datenbankarbeit von wirklich fachmännischer Leistung unterscheiden.

Security Engineers sind möglicherweise den größten Risiken durch LLM-Abhängigkeit ausgesetzt, da Sicherheit eine grundlegend kontradiktorische Denkweise erfordert, bei der sie darüber nachdenken, wie Eindringlinge Systeme angreifen oder kompromittieren. KI-Systeme, die in erster Linie auf öffentlich zugänglichem Code und Dokumentation trainiert sind, können möglicherweise nicht das kreative Denken angemessen repräsentieren, das erforderlich ist, um neue Angriffsvektoren zu identifizieren oder robuste Verteidigungsstrategien zu entwickeln. Security Engineers, die von KI-Unterstützung abhängig werden, können ein falsches Gefühl der Sicherheit entwickeln und dabei kritische Schwachstellen übersehen.

DevOps Engineers und Infrastrukturexpertinnen stehen vor besonderen Herausforderungen, da ihre Arbeit oft das Verständnis der komplexen Interaktionen zwischen mehreren Systemen, Tools und Umgebungen erfordert. Die für das Infrastrukturmanagement erforderlichen Fähigkeiten zur Fehlerbehebung entwickeln sich durch direkte Erfahrungen mit Systemausfällen und die schrittweise Aneignung von Wissen darüber, wie verschiedene Komponenten unter verschiedenen Bedingungen interagieren. LLM-Unterstützung kann Standardlösungen bieten, erfasst jedoch möglicherweise nicht das umgebungsspezifische Wissen, das den Unterschied zwischen angemessenem und exzellentem Infrastrukturmanagement ausmacht.

Dieses Phänomen erweist sich als noch problematischer, wenn man die kollaborative Natur der Softwareentwicklung berücksichtigt. Entwickler, die unter einer übermäßigen Abhängigkeit von LLM leiden, haben oft Schwierigkeiten in Pair-Programming-Sitzungen oder Code-Review-Diskussionen, weil sie nicht das notwendige tiefgreifende Verständnis entwickelt haben, um ihre Überlegungen zu erklären oder ihre Implementierungsentscheidungen zu verteidigen. Ihr Wissen wird oberflächlich und fragmentiert und besteht eher aus KI-generierten Lösungen als aus prinzipiellem Verständnis.



Source link

Entwicklung & Code

Kommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

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)



Source link

Weiterlesen

Entwicklung & Code

Clean Architecture und Co.: Softwarearchitektur mit Mustern strukturieren


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

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 Eschhole

Matthias Eschhole

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


Infografik Vergleich zwischen Clean Architecture und Schichtenarchitektur

Infografik Vergleich zwischen Clean Architecture und Schichtenarchitektur

Vergleich zwischen Clean Architecture und Schichtenarchitektur (Abb. 1).

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.


Infografik Mustersprache des taktischen Domain-driven Design

Infografik Mustersprache des taktischen Domain-driven Design

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.

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.


Infografik Elemente der Mustersprache des taktischen Domain-driven Design

Infografik Elemente der Mustersprache des taktischen Domain-driven Design

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


Infografik Das Architekturmuster Package by Layer

Infografik Das Architekturmuster Package by Layer

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.


Infografik Architekturmuster Package by Feature

Infografik Architekturmuster Package by Feature

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


Infografik Architekturmuster in Package by Component (Abb. 6).

Infografik Architekturmuster in Package by Component (Abb. 6).

Das Architekturmuster in Package by Component (Abb. 6).



Source link

Weiterlesen

Entwicklung & Code

Ein Tag im Leben eines Softwarearchitekten – Überleben im Unternehmensdschungel


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

Weiterlesen nach der Anzeige


Michael Stal

Michael Stal

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.

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.

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.



Source link

Weiterlesen

Beliebt