Skalierbare IT-Systemarchitekturen - Eine wissenschaftliche Zusammenfassung

1 Zusammenfassung

In diesem Lernportfolio werden verschiedene Thematiken hinsichtlich Skalierbarkeit und Systemarchitekturen detailliert erlautert und mit persönlichen Erkenntnissen und Reflexionen abgerundet. Folglich werden zwölf Unterkapitel beschrieben, bei dem der Inhalt basierend auf dem Vorwissen und einer wissenschaftlichen Literaturrecherche aufbaut.Des Weiteren werden kapitelabhangige Forschungsfragen aufgestellt und hinreichend bearbeitet und beantwortet. Zudem weist jedes Unterkapitel den Punkt Erkenntnisse auf, der neue Bezüge zwischen den Themen verdeutlicht. Es wird auf den Erkenntnisgewinn eingegangen, der wahrend der Bearbeitung der Themen aufgetaucht ist. Allgemeinbetrachtet wird eine Vielzahl an Schnittstellen diverser Themen erkenntlich, die in den jeweiligen Kapiteln naher dargestellt werden, um ein insgesamtes groBes Bild vom Ganzen erstellen zu können. Des Weiteren wird jedes Unterkapitel mit einer persönlichen Reflexion abgeschlossen, welche vor, wahrend und nach der Veranstaltung hinsichtlich des untersuchten Themas entstanden ist.

Das erste zentrale Kapitel, welches Softwarearchitekturen thematisiert, beschaftigt sich mit derstrategischenBetrachtungsweise der Architekturmustern für Software. Das darauffolgende Kapitel behandelt Charakteristiken der Vorgehensmodelle und des Softwarelebenszyklus. Das nachste Kapitel erlautert die Thematik Schnittstellen im Zuge der Softwaresysteme. Fortlaufend beschaftigt sich das vierte Unterkapitel mit den Prinzipien und Werkzeugen des Domain-Driven Designs. Nachfolgend wird innerhalb des Kapitels Persistenz die Eigenschaften der Speicherungen betrachtet. Das sechste essenzielle Kapitel Skalierbarkeit, Nebenlaufigkeit und Parallelitat behandelt die Charakteristiken, Eigenschaften und Arten der Thematik. Folglich wird im siebten Kapitel das Thema verteilte Systeme definiert und erklart.Das nachste Thema behandelt Microservices inklusive CQRS als ein mögliches Softwaremuster im Zuge der Skalierbarkeit. Das darauffolgende Thema legt die Definition und Eigenschaften der Virtualisierung dar, welches als Grundbaustein für das folgende Kapitel Cloud- Architekturen ist, worin die strategischen Perspektiven des Cloud-Computings detailliert erklart werden. Fortgeführt wird das Lernportfolio mit dem elften Thema, welches fehlertolerante Systeme und die Eigenschaften behandelt. AbschlieBend wird das Lernportfolio mit dem letzten Thema Automatisierung und Monitoring mit Aspekten der kontinuierlichen Softwarebereitstellung abgeschlossen.

2 Softwarearchitekturen

2.1 Inhalte

Mein Vorwissen umfasst folgende Eigenschaften bezüglich Softwarearchitektur: Eine Softwarearchitektur ist eine definierte Struktur, um Problemstellungen innerhalb der Softwareentwicklung verstandlich lösen zu können 1. Es werden innerhalb der Softwarearchitekturen die Komponenten und die Kommunikation untereinander in einem System beschrieben. Dabei ist eine Softwarearchitektur unterstützend, um im Rahmen der Softwareentwicklung sowohl funktionale als auch nicht funktionale Anforderungen zu erfüllen 2.

Nach einer tiefergehenden Recherche konnte folgendes ermittelt werden: Die Softwaresystemstrukturen werden durch eine Softwarearchitektur definiert. Dabei werden innerhalb der Architektur die einzelnen Komponenten, die dazugehörigen Beziehungen und die Kommunikation untereinander dargestellt. Des Weiteren werden mittels Schnittstellen die externen Attribute der Komponenten beschrieben 1. Das Themengebiet Schnittstellen wird detailliert im Unterkapitel Schnittstellen / APIs erlautert. Im Zuge der Softwarearchitektur wird ein Entwurf verwendet, um anhand der Anforderungen eine Software zu entwickeln. Dabei wird zwischen dem Grobentwurf und dem Feinentwurf entschieden. Innerhalb des Grobentwurfs wird das System als groBes Ganzes betrachtet. Im Gegensatz dazu werden innerhalb des Feinentwurfs die einzelnen Bausteine und Komponenten detailliert beschrieben und aufgebaut 1. 3 weitet die Thematik des Entwurfs aus und empfiehlt innerhalb des Entwurfs potenzielle zukünftige Anderungen einer Software miteinzubeziehen. So sollen die Anforderungserhebung und die Anforderungsdefinierung zukunftsorientiert sein, um dementsprechend die Architektur der Software auszulegen. Des Weiteren können Erfahrungen verwandter Software übernommen werden, um innerhalb der Entwicklung der Architektur vorbeugend mögliche Probleme zu umgehen 3.

In der Architektur existieren diverse Sichten bezüglich des Softwaresystems. 1 ermittelt die statische Sicht, die Laufzeitsicht, die Verteilungssichten und die Kontextsichten. 4 weitet die Sichten um die logische Sicht, die prozess-orientierte Sicht, die entwicklungs- orientierte Sicht und die physische Sicht aus. Des Weiteren werden im Rahmen der Dokumentation einer Softwarearchitektur die Sichten des Quellcodes, der Module, der Ausführung und des Konzepts wichtig. Weiterführend sind die Prinzipien der Architektur für den Entwurf einer Software, unter der Berücksichtigung der Anforderungen, maBgebend. Beispiele für Prinzipien ist das Prinzip der losen Kopplung oder das Prinzip der hohen Kohasion, weitere Prinzipien wurden von 3 erlautert.

Die Umsetzung der Software und somit der Softwarearchitektur ist abhangig von den Anforderungen des Kunden. Dabei beschaftigen sich die funktionalen Anforderungen mit den Funktionen innerhalb einer spezifischen Umgebung. Die nicht-funktionalen Anforderungen oder technische Anforderungen beziehen sich auf die funktionalen Anforderungen und beeinflussen die komplette Softwarearchitektur.

Insgesamt betrachtet, sind die Anforderungen ausschlaggebend, wie ein Softwaresystem entworfen und umgesetzt wird. Aufgrund dessen werden die Anforderungen naher behandelt, um die folgende Forschungsfrage zu beantworten: Welche nicht-funktionale Anforderungen sollten erfüllt werden, um ein qualitatsvolles Softwaresystem zu entwickeln? Diesbezüglich hat 1 die Anforderungen Wartbarkeit, Weiterentwickelbarkeit, Betriebssicherheit, Zuverlassigkeit, Effizienz, Benutzbarkeit und Portabilitat definiert, um ein qualitatsvolles Softwaresystem zu entwickeln.

Die nicht-funktionale Anforderung Wartbarkeit ist ein Qualitatsmerkmal, welches die Anpassbarkeit eines Softwaresystems definiert und inwieweit Anderungen durchgeführt werden können. Die Wartbarkeit unterteilt sich weitgehend in die Untermerkmale Analysierbarkeit, Anderbarkeit, Stabilitat, Testbarkeit, Verstandlichkeit und Modifizierbarkeit 1.

Softwaresysteme werden dem Softwarelebenszyklus zufolge, welches in dem Kapitel Vorgehensmodelle / Softwarelebenszyklus naher beschreiben wird, tendenziell langer im Betrieb bleiben. Deshalb ist die Weiterentwickelbarkeit oder Nachhaltigkeit eine weitere nötige Anforderung, um langfristig das Softwaresystem einzusetzen. Dies unterteilt sich in die Untermerkmale Analysierbarkeit, Anderbarkeit, Testbarkeit, Portabilitat, Erweiterbarkeit und Integritat der Architektur 1.

Im Zuge der Sicherheit muss die Betriebssicherheit die unautorisierten Zugriffe abwenden. Dies untergliedert sich in die Vertraulichkeit, in die Integritat, in die Verfügbarkeit, in die Zugriffssteuerung und in die Authentifizierung 1.

Die Zuverlassigkeit garantiert die Leistung des Softwaresystems innerhalb unterschiedlicher Voraussetzungen. Diese Anforderung wird je nach Definition in die Teilbereiche Reife, Fehlertoleranz und Wiederherstellbarkeit untergliedert 1.

Die Effizienz eines Softwaresystems bezieht sich auf die Leistung unter der Berücksichtigung der nötigen Ressourcen innerhalb der Voraussetzungen und wird in Zeitverhalten und Verbrauchsverhalten unterteilt 1.

Eine weitere Qualitatsanforderung ist die Benutzbarkeit, die sich mit der Verstandlichkeit gegenüber dem Nutzer beschaftigt. Die weitgehenden Teilmerkmale sind die Verstandlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivitat und Konformitat der Benutzbarkeit 1.

Als weitere Qualitatsanforderung wird die Portabilitat erlautert. Diese behandelt die einfache Transportierung des Systems in eine andere Umgebung. Weitere Merkmale der Portabilitat sind Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit und Konformitat der Portabilitat 1.

2.2 Erkenntnisse

Die Softwarearchitektur ist ein umfassendes Thema, welches die Blaupause für die Entwicklung eines Softwaresystems ist. Der Entwurf dient dazu, die Softwarearchitektur in Beachtung der Anforderungen zu erstellen. Dabei müssen die Sichten, Prinzipien und Anforderungen beachtet werden, um einen Ausgangspunkt für die technische Umsetzung anzubieten. Im Zuge einer qualitativhochwertigen Softwarearchitektur sind innerhalb von ISO-Normen diverse Qualitatsanforderungen definiert. Dieses Kapitel weist eine Schnittstelle mit der Thematik Persistenz auf, welche ebenfalls innerhalb Architekturen geplant wird. Zudem greifen die Kapitel Verteilte Systeme, Fehlertolerante Systeme und Microservices inklusive CQRS auf dieses zu und verwenden grundlegende Merkmale der Architekturen.

2.3 Reflexion

Im Rahmen meines Bachelorstudiums beschaftigte ich mich mit der operativen Ebene der Softwarearchitekturen. Hierbei wurden einzelne Architekturen und Muster naher diskutiert. Wahrend der Verfassung dieses Kapitels konnte ich die strategische Sicht der Softwarearchitekturen anschneiden. Dabei erkannte ich, dass das Thema Softwarearchitekturen sehr umfangreich ist, welches die gesamte operative Umsetzung stark beeinflusst und somit folglich das gesamte Softwareprodukt ausmacht.

3 Vorgehensmodelle / Softwarelebenszyklus

3.1 Inhalte

Durch mein bestehendes Vorwissen kenne ich bereits grundlegende Informationen bezüglich des Themas. Ein Vorgehensmodell umfasst diverse Prozesse, um eine Übersicht der Softwareentwicklung zu gewahrleisten und die Komplexitat innerhalb dieser gering zu halten. Beispiele für Vorgehensmodelle sind das Wasserfallmodell, das SCRUM-Modell und das Kanban-Modell. Innerhalb dieser Vorgehensmodelle wird der Softwarelebenszyklus beschrieben, der in der Regel die Phasen Spezifikation, Entwurf, Implementierung, Installation und Betrieb behandelt 5.

Fortlaufend konnte ich durch eine Literaturrecherche zusatzliche vertiefende Informationen sammeln. Ein standardisiertes Vorgehen ist zwingend notwendig, damit Softwareprojekte erfolgreich durchgeführt werden können. Hierfür werden Vorgehensmodelle verwendet, um im Rahmen des Projektverlaufs entsprechende Produktumsetzungen mit einer nötigen Qualitat zu erreichen. Des Weiteren gibt das Vorgehensmodell einen Rahmen wieder, um in diesem einen zeitlichen Ablauf innerhalb der Entwicklung wiederzugeben 6. Weiterführend beschreibt 7, dass Vorgehensmodelle eine sehr vereinfachte Reprasentation des Softwareprozesses sind. Des Weiteren definiert das Vorgehensmodell die Einbindung des Projekts innerhalb des Unternehmens 8.

Es existiert eine Reihe von diversen Vorgehensmodellen, die 9 in drei groBe Gruppen zusammengefasst werden kann. Neben den klassischen plangetriebenen Vorgehensmodellen existieren noch die agilen Vorgehensmodelle und die hybriden Vorgehensmodelle, die die Theorien der plangetriebenen und agilen Vorgehensmodelle vereinen. Es existiert jedoch nicht die eindeutige Tendenz zu einem gewissen Vorgehensmodell. Die Auswahl des Vorgehensmodells ist abhangig von der Art der Software-Entwicklung, vom Auftraggeber und von den gesetzlichen Bestimmungen. Beispielsweise wird eine sicherheitskritische Software mit einem plangetriebenen Vorgehensmodell umgesetzt, da die Analyse und Dokumentation vor der technischen Umsetzung erledigt wird 7. Im Gegensatz zu dem festen plangetriebenen Vorgehensmodell sind die agilen Vorgehensmodelle flexibler. Nach den Prinzipien des agilen Manifests werden folgende Prinzipien für agile Vorgehensmodelle definiert. Der Kunde wird im Entwicklungsprozess eingeschlossen, sodass Anderungsvorschlage dynamisch umgesetzt werden können. Die Zustellung einer lauffahigen Software entsteht iterativ und inkrementell. Des Weiteren steht die Einfachheit der Entwicklung im Vordergrund. AuBerdem sollen die einzelnen Personen, die sich mit der Entwicklung auseinander setzten, keine vorgeschriebenen Prozesse bezüglich der operativen Tatigkeiten aufgezwungen bekommen 7.

Im Rahmen des Software-Lebenszyklus werden die Phasen eines Softwaresystems definiert, welcher in der folgenden Abbildung dargestellt wird 10.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Software-Lebenszyklus 10

Nach 10 kann der Software-Lebenszyklus in die Phasen Systementwicklung und Systembetrieb, welches die Weiterentwicklung der Software einschlieBt, eingeordnet werden. 8 weitet den Software-Lebenszyklus auf die Phasen Anforderungsfestlegung, Grob- und Feinentwurf, Implementierung, Test und Integration, Erprobung und Inbetriebnahme, Wartung und Weiterentwicklung und AuBerbetriebnahme aus. Zuzüglich entwickelt sich der Lebenszyklus von Software weiter, da die Art und Umgebung der Software im standigen Wandel ist und evolviert 8. Sowohl das Vorgehensmodell als auch der Software-Lebenszyklus sollten beachtet werden, da diese für eine erfolgreiche Entwicklung eines Software-Systems ausschlaggebend sind. Folglich steht die Forschungsfrage im Raum, inwiefern die Vorgehensmodelle den Software-Lebenszyklus aufgreifen und diesen integrieren.

Die Prozesse, die im Rahmen des Software-Lebenszyklus durchgeführt werden, weisen eine hohe Komplexitat auf. Die Vorgehensmodelle greifen die Komplexitat und den Lebenszyklus auf, und definieren darauf basierend einen Rahmen 11. Des Weiteren werden die Entwicklungs- und Einsatzphasen eines Softwaresystems im Rahmen des Vorgehensmodells erklart, um eine einleuchtende und chronologische Strategie zu entwickeln. Zudem werden die einzelnen Aktivitaten innerhalb des Vorgehensmodells in Phasen und Meilensteine zusammengefasst, sodass eine überschaubare Strategie vorhanden ist. Fortführend sind Phasen des Vorgehensmodells weitgehend identisch mit den Phasen des Lebenszyklus. 7 beschreibt die Phasen des plangetriebenen Wasserfallmodells mit der Anforderungsanalyse und -definition, dem System- und Softwaredesign, der Implementierung und Unit-Test, der Integration und Systemtests und dem Betrieb und der Instandhaltung, die fast identisch in der Abbildung 1 wiederzufinden sind.

3.2 Erkenntnisse

Es existiert eine Reihe an verschiedenen Vorgehensmodellen, die sich teils sehr unterscheiden. Dabei ist die Auswahl des Vorgehensmodell abhangig vom Software- System, welches entwickelt wird. Nach 7 ist der aktuellere Standard der Software- Entwicklung die agilen Vorgehensmodelle. Des Weiteren ist das Vorgehensmodell die Schnittstelle, welches das Software-Projekt in das gesamte Unternehmen einbindet. Die verschiedenen Vorgehensmodelle greifen im Kern den Software-Lebenszyklus auf, um die entsprechenden Phasen des Zyklus in einer vereinfachten Form widerzuspiegeln und übersichtlich zu gestalten. Diese Thematik ist ein grundlegender Baustein für die Softwareentwicklung, welche insbesondere hinsichtlich der Skalierbarkeit, Nebenlaufigkeit und Parallelitat Anklang finden wird. Zudem benötigten diverse Muster wie Microservices inklusive CQRS ein Vorgehensmodell, um die Entwicklung multipler Systeme strategisch durchzuführen.

3.3 Reflexion

Die Erkenntnis, dass die Entwicklung von Software nach agilen Methoden fast ein Standard ist, kann ich aus bisherigen Erfahrungen bestatigen. Jedoch ist eben diese agile Vorgehensweise, je nach Softwaretyp, nicht immer direkt die richtige Lösung. Weiterführend kannte ich den Lebenszyklus von Software nur oberflachlich, konnte jedoch nun erkennen, dass dieser die einzelnen Vorgehensmodelle weitgehend beeinflusst. Da die Art der Software sich konstant andert und weiterentwickelt, wie zum Beispiel neue Virtual-Reality-Apps, steht der Software-Lebenszyklus und folglich die Vorgehensmodelle im konstanten Wandel, welche ich innerhalb weiterer Forschungen untersuchen werde.

4 Schnittstellen / APIs

4.1 Inhalte

Ich konnte bereits Vorwissen basierend auf der Vorlesung Grundlagen Verteiler Systeme des Software Engineering Bachelors Studiums sammeln, welches im Folgenden beschrieben wird. Schnittstellen in der Softwareentwicklung sind Kommunikationspunkte zwischen Komponenten oder Prozessen. Durch diese Schnittstellen ist ein Datenaustausch zwischen Programmen möglich. Application Programming Interfaces (APIs) sind explizite Programmierschnittstellen für sowohl Hardware als auch für Software wie für Betriebssysteme oder Datenbanken. Des Weiteren stellen Webservices APIs bereit, um eine Datenkommunikation nach auBerhalb oder auch innerhalb anzubieten. Die Kommunikation kann dabei mittels dem Representational State Transfer (REST) erfolgen, welches für verteilte Systeme essenziell ist.

Um mich tiefer mit dem Thema auseinanderzusetzen, führte ich eine Literaturrecherche durch. Eine Schnittstelle ist ein Berührungspunkt zwischen zwei oder mehreren Systeminstanzen. Weiterführend führt die Schnittstelle die Kommunikationsfunktion zwischen zwei gekoppelten Softwaresystemen durch. Im Themengebiet der Informatik existiert eine groBe Anzahl von verschiedenen Schnittstellen, um die Funktionalitaten der „Mensch-Maschine-Interaktion“ einzuwickeln 12. 12 gibt als Beispiele für mögliche Schnittstellen die Import- und Exportschnittstellen, die Hardwareschnittstellen, die Softwareschnittstellen, die Hardware-Software-Schnittstellen und die Mensch-Maschinen- Schnittstellen an.

Ein Application Programming Interface (API) ist eine Schnittstelle, die Softwaresystem ermöglicht miteinander zu kommunizieren und der Software-zu-Software-Schnittstelle angehört. Dies kann über die API zwischen Anwendungen, Webseiten oder Applikationen geschehen 13. Des Weiteren wird innerhalb der API reguliert, in welcher Form die Kommunikation vonstattengeht. Um eine API entsprechend zu designen, müssen folgende Informationen angegeben werden. Die API muss sowohl die Funktionalitat, sowie den Ort der Erreichbarkeit bereitstellen. Des Weiteren müssen die Eingabe- und Ausgabeparameter und das Service-Level-Agreement (SLA) spezifiziert werden, um überhaupt eine regulierte Kommunikation zu ermöglichen. Damit die API nicht im negativen Sinne ausgenutzt werden kann, muss eine technische Anforderung über das Anfragelimit festgelegt sein. Diese unterliegen folglich den rechtlichen und geschaftlichen Einschrankungen.

AbschlieBend sollte eine ausführliche Dokumentation über die API vorhanden sein 13. Die drei Gruppen, in denen APIs eingeordnet werden können sind die internen API, die Partner API und die öffentlichen API.

Damit eine API strukturiert und übersichtlich entwickelt werden kann, muss dies durch das API Management organisiert werden. Das API Management beschaftigt sich mit der Dokumentation, der Analyse und Statistik, dem Deployment, dem Engagement der Entwickler, der Entwicklungsumgebung, der Lastenoptimierung, der Sicherheit, der Verfügbarkeit, der Monetarisierung und mit der Verwaltung des API-Lebenszyklus 14. Der Lebenszyklus von APIs besitzt die Phasen die Analyse, die Entwicklung, die Veröffentlichung, die AuBerbetriebnahme und die Löschung 14. Der Zyklus wird in der folgenden Abbildung naher visualisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Der API-Lebenszyklus 14

Üblicherweise werden in Webservices REST- Schnittstellen verwendet, um eine API- Kommunikation des Service innerhalb des Softwaresystems und nach auBen hin zu ermöglichen. Die Daten werden über HTTP übertragen, sodass keine weitere Transportschicht nötig ist 1. 13 stellt fest, dass die API eines Unternehmens zwingend eine sehr gut durchdachte REST-API sein muss, damit diesbezüglich das Unternehmen ein erfolgreiches API-System bereitstellen kann. Aufgrund der Etablierung von REST-APIs innerhalb von Webservices, kristallisiert sich die Forschungsfrage, wie eine qualitatsvolle REST-API strategisch entwickelt werden kann.

Die Grundprinzipien einer REST-API sind die Ressourcenorientierung, die Adressierbarkeit, die unterschiedlichen Reprasentationen, die Verknüpfungen, die statuslose Kommunikation und der einheitliche Zugriff auf Ressourcen 15.

Die Ressourcenorientierung beschreibt, dass sich die Anfragen eines Clients auf ein einzelnes Element oder auf eine Liste von Elementen beschranken. Die Adressierbarkeit benennt die eindeutige URL, die eine Ressource abbildet. Eine REST-Antwort kann die Elemente in verschiedene Formate zurückgeben, um die unterschiedlichen Reprasentationen einzuhalten. Durch die Verknüpfung der Ressourcen wird nach einer Abfrage der Zustand des Clients entsprechend verandert. Um die statuslose Kommunikation zu ermöglichen, werden keine spezifischen serverseitigen Kopplungen der Clients durchgeführt, um eine Skalierbarkeit zu ermöglichen. Die standardisierten Zugriffsmethoden von REST sind die Befehle GET, POST, PUT, DELETE, HEAD und OPTIONS 15.

4.2 Erkenntnisse

In allen möglichen Bereichen eines Softwaresystems existieren Schnittstellen, um Kommunikation zwischen verschiedenen Komponenten zu ermöglichen. Insbesondere innerhalb der Netzwerkkommunikation spielen APIs eine wichtige Rolle, um Softwaresysteme miteinander kommunizieren zu lassen. Durch den API-Lebenszyklus werden Parallelitaten zum Software-Lebenszyklus ersichtlich. Um eine API optimal umsetzen zu können, bedarf es einer detaillierten Planung und Dokumentation. Durch die Prinzipien und standardisierten Zugriffsbefehle werden skalierbare Webservices ermöglicht. Durch die mögliche interne Kommunikation von Softwaresystemen innerhalb eines Unternehmens, können REST-Schnittstellen im Rahmen der Microservice- Architektur verwendet werden, welches im Kapitel Microservices inklusive CQRS naher erlautert wird. Zudem hat das Thema Cloud-Architekturen ein Berührungspunkt mit diesem, da innerhalb der Cloud mittels APIs die diversen Services bereitgestellt werden.

4.3 Reflexion

APIs sind ein wichtiges Thema in den heutigen Softwaresystemen. Basierend auf mein Vorwissen über die operativen Umsetzungen von REST-APIs konnte ich nun mein Wissen auf der strategischen Ebene vertiefen. Das API-Management beschreibt die strategische Planung und Umsetzung von APIs, um die operative Umsetzung überhaupt zu ermöglichen. Des Weiteren bringen die Prinzipien von REST Hilfestellung, um ein qualitatsvolles Konzept von REST-APIs zu designen.

5 Domain-Driven Design

5.1 Inhalte

Bezüglich dem Thema Domain-Driven Design bestand vor der Vorlesung kein Vorwissen. Durch eine Literaturrecherche und dem Impulsvortrag konnte ich ein naheres Verstandnis zum Thema aufbauen, welches im Folgenden beschrieben wird.

Die Philosophie Domain-Driven Design wurde von Eric Evans im Jahr 2003 gepragt und definiert. Als initialen Impuls erkennte er, dass Software-Designer seit 20 Jahren die Modellierung und das Designen von Domanen als problematische Themen kristallisiert haben, jedoch nicht einheitlich erklart wurde, wie damit handzuhaben ist. Folglich ist nach Evans die Definition des Domain-Driven Designs eine Denkweise und eine Reihe von Prioritaten, die darauf abzielen, Softwareprojekte, die sich mit komplizierten Domanen befassen müssen, zu beschleunigen 16. Alternativ definiert 17 Domain-Driven Design mit der Fokussierung auf den Bereich, in dem die Software tatig sein wird. Insgesamt betrachtend ist der Zweck der Software, eine bestimmte Domane zu verstehen und zu verbessern. Des Weiteren müssen Design- und Entwicklungspraxen verknüpft werden, welches durch Domain-Driven Design erfolgreich dargestellt werden kann, um zielführend eine Lösung zu finden.

[...]