Mit dem Fortschritt der Informationstechnologie und der Entwicklung neuer Software suchen Unternehmen nach immer mehr Möglichkeiten, um relativ schnell sichere Anwendungen und Systeme zu erstellen, die alle Bedingungen abdecken und einfach zu testen und zu entwickeln sind. Durch Versuch und Irrtum wurde ein Ansatz entwickelt, der von vielen Unternehmen als idealer Weg zum Erstellen von Software angesehen wird.
Es geht um Domain Driven Design. Was genau ist dieser Ansatz zur Softwareentwicklung im Unternehmen?
Domain Driven Design (kurz DDD) – was ist das für ein Ansatz?
Ganz am Anfang lohnt es sich zu definieren, was genau der DDD-Ansatz ist. Es ist eine Möglichkeit, Anwendungen und Systeme zu erstellen, die im Wesentlichen die Anforderungen des Unternehmens widerspiegeln sollten – geschäftliche Annahmen, die gleichzeitig zu Voraussetzungen werden, die in die Software aufgenommen werden.
Welche Inputs liegen der DDD-Methode zugrunde? Zuallererst sollte das Design jeder Software auf einer gleichberechtigten Zusammenarbeit zwischen Programmierern und direkt mit dem Unternehmen verbundenen Personen basieren, die gleichzeitig die Zielkunden der Lösung sind. Die zweite Voraussetzung für die Erstellung von Systemen nach der DDD-Methode ist die Gestaltung der Projektlogik in Form von Domänen.
Was ist eine Domäne? Kurz gesagt handelt es sich um ein bestimmtes Geschäftsfeld, das umgesetzt werden muss. Ein Bereich, der mit neu erstellter oder entwickelter Software verbessert werden muss. Abhängig von der Wichtigkeit und Essenz eines bestimmten Konzepts und einer bestimmten Funktionalität können wir Domänen unterteilen in:
- Die Hauptdomänen, die den wichtigsten Teil des Systems darstellen und für die wichtigsten Funktionen verantwortlich sind.
- Support-Domains, die Erweiterungen der Hauptdomain sind – ohne sie sind Support-Domains wertlos.
- Allgemeine Domänen, die wichtige, aber optionale Funktionen sind.
Woraus besteht DDD?
Der Prozess der Erstellung neuer Software basierend auf den Prinzipien des Domain Driven Design unterscheidet sich etwas vom traditionellen Ansatz der Softwareentwicklung, der eine Reihe technischer Probleme im Zusammenhang mit der Verarbeitung von Mechanik, Dateneingabe und -ausgabe, Kommunikation mit dem Server und der Datenbank umfasst und Integration mit anderen Tools, die von der Organisation verwendet werden.
Die DDD-Programmierung besteht hauptsächlich aus Domänenmodellen (Stamm-, Unter- und allgemeine Domänen), die eine sehr grundlegende Implementierung der Geschäftsparameter enthalten, die in der Software enthalten sein sollten. Es ist sehr wichtig, dass der Programmierer, der für die Entwicklung des Codes verantwortlich ist, den Zweck der Erstellung neuer Software und den Wert der Domain versteht. DDD kann nicht darauf verzichten, eine Sprache zu definieren, die es Domänenexperten und Programmierern ermöglicht, diese Sprache leicht zu verstehen. Für diesen Ansatz wurde diese Sprache die allgegenwärtige Sprache genannt.
Welche Schwierigkeiten können bei der Verwendung des Domain Driven Design-Ansatzes auftreten?
Was ist das größte Problem bei der Verwendung der DDD-Methode? Zunächst einmal ist es die Kommunikation zwischen der fachlichen und der technischen Seite. In der Regel sollte in einem DDD-Ansatz immer Platz für einen Domänenexperten sein, der über fundierte Kenntnisse des Ansatzes verfügt und selbst als „Kompilierer“ in der Geschäfts- und IT-Kommunikation fungiert.
Aufgrund des relativ geringen Anteils an Projekten, die nach der DDD-Methode erstellt werden, ist es sehr schwierig, eine Person zu finden, die eine solche Rolle mit vollem Engagement übernehmen könnte. Der Mangel an Erfahrung für Programmierer beim Erstellen unter Verwendung der DDD-Methodik kann auch zusätzliche Schwierigkeiten verursachen.
Vor- und Nachteile des DDD-Ansatzes
Beginnen wir mit den Vorteilen eines Domain Driven Design-Ansatzes bei der Erstellung neuer Software. Zunächst einmal ist es eine großartige Lösung für komplexe Projekte, bei denen die Anzahl der Funktionen, Implementierungsziele und unterschiedlichen Ebenen so groß ist, dass es schwierig ist, sie in einem traditionellen Anwendungsdesign konzeptionell zu erfassen. Der DDD-Ansatz erfüllt die tatsächlichen Bedürfnisse des Unternehmens – es gibt keinen Raum für halbe Sachen – wenn die Domain vom Programmierer richtig interpretiert wird, wird sie in voller Übereinstimmung mit den Bedürfnissen des Endbenutzers implementiert. Hervorzuheben sind auch die relativ geringen Kosten für die Entwicklung der Anwendung, die von Anfang an nach dem DDD-Ansatz erstellt wurde.
Was sind die Nachteile dieser Technik? Der Hauptnachteil ist wenig Übung in der Verwendung dieser Art der Entwicklung neuer Software. Aus diesem Grund birgt der Einstieg in eine neue Strategie aus Sicht des Projektteams die Gefahr eines völligen Missverständnisses des Konzepts und damit des Scheiterns.
Die anfänglichen Produktionskosten für das Entwerfen und Erstellen einer Anwendung mit der DDD-Methodik sind höher, was sich sicherlich auf den geringen Prozentsatz der Projekte auswirkt, die auf diese Weise implementiert werden.
Wie verwende ich DDD in meinem eigenen Projekt?
Damit DDD in unserem Projekt praktikabel ist, müssen wir tatsächlich bei Null anfangen. Es ist nicht möglich, ein domänengetriebenes Designkonzept teilweise zu übernehmen, bei dem der Rest des Modells auf traditionelle Weise entworfen wird. In diesem Fall ist die Zufriedenheit mit dem Endprodukt sowohl beim IT-Team als auch beim Endbenutzer gering.
