Immer wieder erleben wir es, dass Entwickler dazu neigen, technisch komplexere Lösungen zu bauen als es eigentlich nötig wäre. Die umzusetzende Business-Logik tritt dadurch im Code in den Hintergrund. Wer den Code liest, erkennt nicht direkt, welche fachlichen Anforderungen umgesetzt wurden. Domain Driven Design (DDD) ist ein Ansatz, der versucht, dieses Problem zu lösen.
Der Begriff “Domain Driven Design“ geht zurück auf ein Buch von Eric Evans aus dem Jahr 2004. In diesem Buch formuliert er das Ziel, die fachliche Komplexität im Code sichtbar abzubilden.
Mit dieser Aussage stieß das Buch schon damals bei uns von open knowledge auf offene Ohren, weil wir die identifizierten Probleme nur allzu gut aus unseren Kundenprojekten kannten. Damals wie heute erleb(t)en wir viel zu häufig, dass sich Entwickler viel lieber auf Technologie stürzen, anstatt zu versuchen, die Fachlichkeit zu erfassen. Was damals technologische Workarounds (genannt Patterns oder Best Practices) für kompliziertes EJB-Verhalten war, sind heute Docker, Kubernetes, Cloud und co.
Natürlich sind das alles Themen, die im Rahmen eines Software-Projektes gelöst werden müssen. Sie sollten aber nicht den Kern des Projektes ausmachen.
Eric Evans schreibt dazu in seinem Buch: „For most software projects, the primary focus should be on the domain and domain logic“, auf deutsch: „Der Fokus der meisten Software-Projekte sollte auf der Domäne und der Domänenlogik liegen.“
Mit Domain-Driven Design bekommt man einen Werkzeugkasten, um genau das zu erreichen.
Wir schreiben Software, um einen bestimmten fachliche Kontext abzubilden. Diese Fachlichkeit ist also gewissermaßen der Problemraum, in dem sich unsere Software bewegt. Ziel von Software-Entwicklung ist es, für konkrete Probleme innerhalb dieses Problemraums Lösungen zu realisieren. Um das sinnvoll und effizient leisten zu können, ist ein tiefes Fachverständnis in der Domäne erforderlich. DDD ist ein Konzept, um genau das zu erreichen.
Eric Evans beschreibt den Software-Entwicklungsprozess nach DDD als ein kontinuierliches Lernen der technischen Experten über die fachliche Domäne.
Eine weitere Aussage aus dem Buch von Eric Evans ist: „Komplex Domain Design should be based on a model“, auf deutsch: „Komplexes Domänen-Design sollte auf einem Modell basieren."
Häufig wird das Domänenmodell begrifflich mit der Domäne gleichgesetzt. Das ist allerdings nicht ganz richtig.
Eine berümte Aussage von George Box lautet: „All models are wrong, but some are useful“, also: „Alle Modelle sind falsch, aber einige sind nützlich“. Diese Aussage war ursprünglich zwar auf statistische Modelle bezogen, lässt sich aber auf Domänen-Modelle übertragen: Ein Modell kann niemals die gesamte Domäne abbilden. Es ist immer eine Abstraktion und das ist auch das Ziel von Modellierung. Es geht darum, die wichtigsten Aspekte aufzunehmen und die unwichtigen wegzulassen. Unsere Aufgabe als Software-Entwickler ist es, diese Aspekte herauszuarbeiten. Ein gutes Modell ist maßgeschneidert für die Aufgabe.
Das impliziert auch, dass es mehrere Modelle für dieselbe Fachlichkeit gibt. Die Herausforderung für die Domänen-Modellierung ist es, das Modell zu finden, das am besten geeignet ist, um das konkrete Problem zu lösen, welches wir mit der Software umsetzen wollen.
Da sich dank agiler Software-Entwicklung die konkreten Aufgaben der Software im Laufe der Entwicklung ändern können, wird sich auch das Modell kontinuierlich weiterentwickeln.
Software-Projekte bewegen sich im Spannungsfeld von Endbenutzern, fachlichen Experten und technischen Experten. Ein wichtiger Teilaspekt des Fokusses auf die Fachlichkeit und des kontinuierlichen Lernens ist eine gemeinsame Sprache. Eric Evans nennt sie Ubiquitous Language (allgegenwärtige Sprache).
In vielen Softwareprojekten ist es so, dass Endbenutzer, fachliche Experten und technische Experten unterschiedliche Begriffe für dieselben Sachverhalte verwenden, so dass in allen Phasen des Software-Entwicklungsprozesses immer wieder übersetzt werden muss. Das ist einerseits teuer, weil es Zeit kostet, andererseits sind dadurch auch Missverständnisse vorprogrammiert. Ziel von Domain Driven Design ist es, die Verwendung unterschiedlicher Begriffe komplett zu unterbinden, in dem bewusst darauf geachtet wird, dass alle dieselbe Sprache sprechen.
Es gibt in der Domäne sicherlich eine Fachsprache. Diese bildet die Basis der Ubiquitous Language. Es kommt aber regelmäßig zu Situationen, in denen die Fachsprache nicht ausreicht, weil die verwendeten Begriffe nicht präzise genug oder eben nicht eindeutig sind. Dann gilt es, diese Situation zu erkennen und sich auf einen Begriff zu einigen.
Es muss dann darauf geachtet werden, dass dieser Begriff durchgängig verwendet wird, also in Fachdiskussionen, Anforderungsbeschreibungen und im Code (bis hin zur Benennung in der Datenbank).
Unserer Erfahrung nach eignet sich ein Event-Storming-Workshop sehr gut, um eine Ubiquitous Language initial einzuführen und später zu etablieren.
Eric Evans teilt sein Buch in zwei Prinzipien ein: Tactical Design und Strategic Design.
Beim Tactial Design geht es darum, wie ein konkretes Domänenmodell gefunden, aufgebaut und implementiert werden sollte. Dabei gibt es die Bausteine Services, Aggregates, Entities, Value Objects, Repositories und Factories. Auf diese Bausteine und ihre mögliche Implementierung gehe ich in einem weiteren Blogartikel näher ein.
Das Strategic Design betrachtet eine größere Ebene, nämlich den Fall dass die umzusetzende Domäne zu groß ist, um in einem einzigen Modell sinnvoll abgebildet zu werden. Das Domänenmodell muss dann aufgeteilt werden. Wie das gelingen kann, ohne die Vorteile von DDD zu verlieren und wie die verschiedenen Teilmodelle miteinander kommunizieren können, ist Teil der Betrachtung von Strategic Design.
In der breiten Öffentlichkeit hat dieser Aspekt von Domain Driven Design insbesondere seit dem Aufkommen von Microservice-Architekturen wieder an Beachtung gewonnen, weil das Buch von Eric Evans einige Konzepte beschreibt, die sehr gut geeignet zu sein scheinen, um die Kommunikation in Microservice-Landschaften zu modellieren. Und tatsächlich kann man feststellen, dass viele der Prinzipien aus dem Strategic Design auf Microservice-Architekturen übertragen werden können. Insbesondere das Konzept der Bounded Contexts hilft dabei, den richtigen Schnitt für Microservices zu finden, aber auch die anderen beschriebenen Patterns sind teilweise sinnvoll, um das Zusammenspiel der einzelnen Services festzulegen.
Alberto Brandolini, der Erfinder von Event Storming, schreibt in seinem Buch „It’s not the expert knowledge that really matters. […] It’s developer understanding that gets captured in code and released in production.” – auf deutsch: Es ist nicht das Expertenwissen, auf das es ankommt. Es ist das, was die Entwickler darunter verstehen, was sich im Code widerspiegelt und in die Produktionsumgebung gebracht wird.
Jeder Projektteilnehmer hat eine eigene Sicht auf das, was umgesetzt werden soll und ein eigenes Verständnis davon. Ziel von Domain Driven Design ist es, die verschiedenen Sichten so gut wie möglich zu vereinen. Das impliziert auch, dass die Entwickler kontinuierlich über die Domäne lernen.
Diese Anforderung an die Entwickler ist aber zugleich eine Herausforderung. Entwickler sind dazu angehalten, das Domänen-Modell zusammen mit den Fachexperten aktiv weiterzuentwickeln. Das impliziert einerseits eine hohe Eigenverantwortung der Entwickler. Es ist ihre Aufgabe, zu erkennen, wenn das bestehende Modell nicht ausreicht, um eine neue Anforderung umzusetzen, wenn es also erweitert werden muss. Nicht jeder Entwickler ist willens oder in der Lage dazu, das zu tun.
Im Buch „Clean Code“ von Robert C. Martin gibt es neben anderen Zitaten ein Zitat von Ward Cunningham:
„You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.“
auf deutsch: Du weißt, dass du an sauberem Code arbeitest, wenn sich herausstellt, dass sich jede Methode, die man liest, als genau das herausstellt, was man erwartet hat. Darüber hinaus ist es schöner Code, wenn der Code so aussieht, als wenn die Sprache genau dazu gemacht worden wäre, das Problem zu lösen.
Dieses Zitat beschreibt meiner Meinung nach das Ziel des Codes, der mit DDD geschrieben wurde, recht gut.
Solcher Code hat den Vorteil, dass auch das Fachwissen, was über die Modellierung in den Code eingeflossen ist, erhalten bleibt, weil es jeder, der den Code liest, verstehen kann. Eine Voraussetzung dafür ist natürlich, dass sich das Modell auch 1:1 im Code wiederfinden lässt.
Ein Nachteil dieses Vorgehens ist, dass es initial sehr aufwendig sein kann, solchen Code zu schreiben. In einem Projekt, in dem es wenig Fachlichkeit gibt, kann das Vorgehen zu erheblichem Mehraufwand führen, der später keinen Nutzen hat.
Um zu entscheiden, ob der Einsatz von DDD sinnvoll ist, sollte zunächst der Fokus auf Business-Regeln, fachliche Validität und Invarianten gelegt werden. Identifiziert man diese, lohnt sich ein Einsatz von DDD.
Für zu technologische Projekte ohne (oder mit wenig) Fachlichkeit ist DDD nicht geeignet, weil es zu aufwendig ist.
DDD stellt die Kommunikation zwischen Domänenexperten und technischen Experten in den Fokus des Entwicklungsprozesses. In vielen Software-Projekten wird genau diese Kommunikation vernachlässigt. DDD kann ein Hebel sein, um die Kommunikation in solchen Projekten in Gang zu bringen. Durch die Verwendung der gemeinsamen Sprache wird dafür gesorgt, dass Missverständnisse vermieden werden.
Jeder kennt sicherlich die Situation: Der Fach-Experte wünscht eine (eigentlich) kleine Änderung, da sie vom bisherigen Modell aber so nicht vorgesehen ist, muss das Modell geändert werden, wodurch das Ticket nur mit hohem Aufwand umzusetzen ist.
Solche Situationen sind nicht immer zu vermeiden.
Mit Domain Driven Design und insbesondere, wenn dem Fach-Experten das Modell geläufig ist, lassen sich solche Situation leichter erkennen (ggf. sogar vom Fach-Experten selbst) und auch viel besser argumentativ untermauern.
Der Fach-Experte hat ein viel besseres Verständnis für entstehende Aufwände.
Der mittlerweile leider verstorbene Stefan Tilkov schreibt in einem Beitrag, dass Domain Driven Design eventuell überbewertet ist. Er bezieht sich dabei insbesondere darauf, dass der Fokus auf Domain Driven Design den Blick darauf verstellen kann, dass es noch andere Möglichkeiten gibt, ein gutes Software-System zu designen. Das gilt nicht nur für das Programmier-Paradigma Objekt-Orientierung (es gibt mittlerweile auch funktionale Adaptionen von Domain Driven Design), sondern z.B. auch für die Verwendung der oben genannten Building Blocks wie Aggregates, Entities, Value Objects usw. Wenn jeder weiß, was darunter zu verstehen ist, ist es zwar sinnvoll, diese zu verwenden. Man sollte aber im Auge behalten, dass auch andere Begriffe gute Möglichkeiten darstellen, ein System zu beschreiben. Stefan Tilkov nennt als Beispiel Document und Agent.
Und tatsächlich führt auch Eric Evans im Laufe seines Buches ja weitere Konzepte wie Policy oder Domain Event ein. Alberto Brandolini verwendet beim Event Storming die neu eingeführten Konzepte von Command und Read Model, die z.B. eher aus dem Architektur-Konzept des CQRS kommen.
Domain Driven Design ist eine von Eric Evans entwickelte Methode, die die Fachlichkeit und deren gemeinsames Verständnis in den Fokus der Software-Entwicklung stellt. Richtig angewendet trägt Domain Driven Design einen wichtigen Teil dazu bei, dass Software erfolgreich entwickelt und später auch gewartet werden kann.
Der Begriff “Domain Driven Design“ geht zurück auf ein Buch von Eric Evans aus dem Jahr 2004. In diesem Buch formuliert er das Ziel, die fachliche Komplexität im Code sichtbar abzubilden.
Mit dieser Aussage stieß das Buch schon damals bei uns von open knowledge auf offene Ohren, weil wir die identifizierten Probleme nur allzu gut aus unseren Kundenprojekten kannten. Damals wie heute erleb(t)en wir viel zu häufig, dass sich Entwickler viel lieber auf Technologie stürzen, anstatt zu versuchen, die Fachlichkeit zu erfassen. Was damals technologische Workarounds (genannt Patterns oder Best Practices) für kompliziertes EJB-Verhalten war, sind heute Docker, Kubernetes, Cloud und co.
Natürlich sind das alles Themen, die im Rahmen eines Software-Projektes gelöst werden müssen. Sie sollten aber nicht den Kern des Projektes ausmachen.
Eric Evans schreibt dazu in seinem Buch: „For most software projects, the primary focus should be on the domain and domain logic“, auf deutsch: „Der Fokus der meisten Software-Projekte sollte auf der Domäne und der Domänenlogik liegen.“
Mit Domain-Driven Design bekommt man einen Werkzeugkasten, um genau das zu erreichen.
Wir schreiben Software, um einen bestimmten fachliche Kontext abzubilden. Diese Fachlichkeit ist also gewissermaßen der Problemraum, in dem sich unsere Software bewegt. Ziel von Software-Entwicklung ist es, für konkrete Probleme innerhalb dieses Problemraums Lösungen zu realisieren. Um das sinnvoll und effizient leisten zu können, ist ein tiefes Fachverständnis in der Domäne erforderlich. DDD ist ein Konzept, um genau das zu erreichen.
Eric Evans beschreibt den Software-Entwicklungsprozess nach DDD als ein kontinuierliches Lernen der technischen Experten über die fachliche Domäne.
Eine weitere Aussage aus dem Buch von Eric Evans ist: „Komplex Domain Design should be based on a model“, auf deutsch: „Komplexes Domänen-Design sollte auf einem Modell basieren."
Häufig wird das Domänenmodell begrifflich mit der Domäne gleichgesetzt. Das ist allerdings nicht ganz richtig.
Eine berümte Aussage von George Box lautet: „All models are wrong, but some are useful“, also: „Alle Modelle sind falsch, aber einige sind nützlich“. Diese Aussage war ursprünglich zwar auf statistische Modelle bezogen, lässt sich aber auf Domänen-Modelle übertragen: Ein Modell kann niemals die gesamte Domäne abbilden. Es ist immer eine Abstraktion und das ist auch das Ziel von Modellierung. Es geht darum, die wichtigsten Aspekte aufzunehmen und die unwichtigen wegzulassen. Unsere Aufgabe als Software-Entwickler ist es, diese Aspekte herauszuarbeiten. Ein gutes Modell ist maßgeschneidert für die Aufgabe.
Das impliziert auch, dass es mehrere Modelle für dieselbe Fachlichkeit gibt. Die Herausforderung für die Domänen-Modellierung ist es, das Modell zu finden, das am besten geeignet ist, um das konkrete Problem zu lösen, welches wir mit der Software umsetzen wollen.
Da sich dank agiler Software-Entwicklung die konkreten Aufgaben der Software im Laufe der Entwicklung ändern können, wird sich auch das Modell kontinuierlich weiterentwickeln.
Software-Projekte bewegen sich im Spannungsfeld von Endbenutzern, fachlichen Experten und technischen Experten. Ein wichtiger Teilaspekt des Fokusses auf die Fachlichkeit und des kontinuierlichen Lernens ist eine gemeinsame Sprache. Eric Evans nennt sie Ubiquitous Language (allgegenwärtige Sprache).
In vielen Softwareprojekten ist es so, dass Endbenutzer, fachliche Experten und technische Experten unterschiedliche Begriffe für dieselben Sachverhalte verwenden, so dass in allen Phasen des Software-Entwicklungsprozesses immer wieder übersetzt werden muss. Das ist einerseits teuer, weil es Zeit kostet, andererseits sind dadurch auch Missverständnisse vorprogrammiert. Ziel von Domain Driven Design ist es, die Verwendung unterschiedlicher Begriffe komplett zu unterbinden, in dem bewusst darauf geachtet wird, dass alle dieselbe Sprache sprechen.
Es gibt in der Domäne sicherlich eine Fachsprache. Diese bildet die Basis der Ubiquitous Language. Es kommt aber regelmäßig zu Situationen, in denen die Fachsprache nicht ausreicht, weil die verwendeten Begriffe nicht präzise genug oder eben nicht eindeutig sind. Dann gilt es, diese Situation zu erkennen und sich auf einen Begriff zu einigen.
Es muss dann darauf geachtet werden, dass dieser Begriff durchgängig verwendet wird, also in Fachdiskussionen, Anforderungsbeschreibungen und im Code (bis hin zur Benennung in der Datenbank).
Unserer Erfahrung nach eignet sich ein Event-Storming-Workshop sehr gut, um eine Ubiquitous Language initial einzuführen und später zu etablieren.
Eric Evans teilt sein Buch in zwei Prinzipien ein: Tactical Design und Strategic Design.
Beim Tactial Design geht es darum, wie ein konkretes Domänenmodell gefunden, aufgebaut und implementiert werden sollte. Dabei gibt es die Bausteine Services, Aggregates, Entities, Value Objects, Repositories und Factories. Auf diese Bausteine und ihre mögliche Implementierung gehe ich in einem weiteren Blogartikel näher ein.
Das Strategic Design betrachtet eine größere Ebene, nämlich den Fall dass die umzusetzende Domäne zu groß ist, um in einem einzigen Modell sinnvoll abgebildet zu werden. Das Domänenmodell muss dann aufgeteilt werden. Wie das gelingen kann, ohne die Vorteile von DDD zu verlieren und wie die verschiedenen Teilmodelle miteinander kommunizieren können, ist Teil der Betrachtung von Strategic Design.
In der breiten Öffentlichkeit hat dieser Aspekt von Domain Driven Design insbesondere seit dem Aufkommen von Microservice-Architekturen wieder an Beachtung gewonnen, weil das Buch von Eric Evans einige Konzepte beschreibt, die sehr gut geeignet zu sein scheinen, um die Kommunikation in Microservice-Landschaften zu modellieren. Und tatsächlich kann man feststellen, dass viele der Prinzipien aus dem Strategic Design auf Microservice-Architekturen übertragen werden können. Insbesondere das Konzept der Bounded Contexts hilft dabei, den richtigen Schnitt für Microservices zu finden, aber auch die anderen beschriebenen Patterns sind teilweise sinnvoll, um das Zusammenspiel der einzelnen Services festzulegen.
Alberto Brandolini, der Erfinder von Event Storming, schreibt in seinem Buch „It’s not the expert knowledge that really matters. […] It’s developer understanding that gets captured in code and released in production.” – auf deutsch: Es ist nicht das Expertenwissen, auf das es ankommt. Es ist das, was die Entwickler darunter verstehen, was sich im Code widerspiegelt und in die Produktionsumgebung gebracht wird.
Jeder Projektteilnehmer hat eine eigene Sicht auf das, was umgesetzt werden soll und ein eigenes Verständnis davon. Ziel von Domain Driven Design ist es, die verschiedenen Sichten so gut wie möglich zu vereinen. Das impliziert auch, dass die Entwickler kontinuierlich über die Domäne lernen.
Diese Anforderung an die Entwickler ist aber zugleich eine Herausforderung. Entwickler sind dazu angehalten, das Domänen-Modell zusammen mit den Fachexperten aktiv weiterzuentwickeln. Das impliziert einerseits eine hohe Eigenverantwortung der Entwickler. Es ist ihre Aufgabe, zu erkennen, wenn das bestehende Modell nicht ausreicht, um eine neue Anforderung umzusetzen, wenn es also erweitert werden muss. Nicht jeder Entwickler ist willens oder in der Lage dazu, das zu tun.
Im Buch „Clean Code“ von Robert C. Martin gibt es neben anderen Zitaten ein Zitat von Ward Cunningham:
„You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.“
auf deutsch: Du weißt, dass du an sauberem Code arbeitest, wenn sich herausstellt, dass sich jede Methode, die man liest, als genau das herausstellt, was man erwartet hat. Darüber hinaus ist es schöner Code, wenn der Code so aussieht, als wenn die Sprache genau dazu gemacht worden wäre, das Problem zu lösen.
Dieses Zitat beschreibt meiner Meinung nach das Ziel des Codes, der mit DDD geschrieben wurde, recht gut.
Solcher Code hat den Vorteil, dass auch das Fachwissen, was über die Modellierung in den Code eingeflossen ist, erhalten bleibt, weil es jeder, der den Code liest, verstehen kann. Eine Voraussetzung dafür ist natürlich, dass sich das Modell auch 1:1 im Code wiederfinden lässt.
Ein Nachteil dieses Vorgehens ist, dass es initial sehr aufwendig sein kann, solchen Code zu schreiben. In einem Projekt, in dem es wenig Fachlichkeit gibt, kann das Vorgehen zu erheblichem Mehraufwand führen, der später keinen Nutzen hat.
Um zu entscheiden, ob der Einsatz von DDD sinnvoll ist, sollte zunächst der Fokus auf Business-Regeln, fachliche Validität und Invarianten gelegt werden. Identifiziert man diese, lohnt sich ein Einsatz von DDD.
Für zu technologische Projekte ohne (oder mit wenig) Fachlichkeit ist DDD nicht geeignet, weil es zu aufwendig ist.
DDD stellt die Kommunikation zwischen Domänenexperten und technischen Experten in den Fokus des Entwicklungsprozesses. In vielen Software-Projekten wird genau diese Kommunikation vernachlässigt. DDD kann ein Hebel sein, um die Kommunikation in solchen Projekten in Gang zu bringen. Durch die Verwendung der gemeinsamen Sprache wird dafür gesorgt, dass Missverständnisse vermieden werden.
Jeder kennt sicherlich die Situation: Der Fach-Experte wünscht eine (eigentlich) kleine Änderung, da sie vom bisherigen Modell aber so nicht vorgesehen ist, muss das Modell geändert werden, wodurch das Ticket nur mit hohem Aufwand umzusetzen ist.
Solche Situationen sind nicht immer zu vermeiden.
Mit Domain Driven Design und insbesondere, wenn dem Fach-Experten das Modell geläufig ist, lassen sich solche Situation leichter erkennen (ggf. sogar vom Fach-Experten selbst) und auch viel besser argumentativ untermauern.
Der Fach-Experte hat ein viel besseres Verständnis für entstehende Aufwände.
Der mittlerweile leider verstorbene Stefan Tilkov schreibt in einem Beitrag, dass Domain Driven Design eventuell überbewertet ist. Er bezieht sich dabei insbesondere darauf, dass der Fokus auf Domain Driven Design den Blick darauf verstellen kann, dass es noch andere Möglichkeiten gibt, ein gutes Software-System zu designen. Das gilt nicht nur für das Programmier-Paradigma Objekt-Orientierung (es gibt mittlerweile auch funktionale Adaptionen von Domain Driven Design), sondern z.B. auch für die Verwendung der oben genannten Building Blocks wie Aggregates, Entities, Value Objects usw. Wenn jeder weiß, was darunter zu verstehen ist, ist es zwar sinnvoll, diese zu verwenden. Man sollte aber im Auge behalten, dass auch andere Begriffe gute Möglichkeiten darstellen, ein System zu beschreiben. Stefan Tilkov nennt als Beispiel Document und Agent.
Und tatsächlich führt auch Eric Evans im Laufe seines Buches ja weitere Konzepte wie Policy oder Domain Event ein. Alberto Brandolini verwendet beim Event Storming die neu eingeführten Konzepte von Command und Read Model, die z.B. eher aus dem Architektur-Konzept des CQRS kommen.
Domain Driven Design ist eine von Eric Evans entwickelte Methode, die die Fachlichkeit und deren gemeinsames Verständnis in den Fokus der Software-Entwicklung stellt. Richtig angewendet trägt Domain Driven Design einen wichtigen Teil dazu bei, dass Software erfolgreich entwickelt und später auch gewartet werden kann.
