Hugendubel.info - Die B2B Online-Buchhandlung 

Merkliste
Die Merkliste ist leer.
Bitte warten - die Druckansicht der Seite wird vorbereitet.
Der Druckdialog öffnet sich, sobald die Seite vollständig geladen wurde.
Sollte die Druckvorschau unvollständig sein, bitte schliessen und "Erneut drucken" wählen.

Domain-Driven Transformation

E-BookEPUBePub WasserzeichenE-Book
312 Seiten
Deutsch
dpunkt.verlagerschienen am04.09.2023
Über den Umbau von IT-Landschaften mit Domain-Driven Design - kompakter, tiefgehender Einblick in Domain-Driven Design (DDD) und die Verwendung der vielfältigen DDD-Techniken in der Praxis - Fokussierung auf Legacy-Systeme und Migration in Richtung gut strukturierter Monolithen und Microservices - Zusammenhang zwischen Transformation der Architektur und der TeamorganisationIn den letzten Jahrzehnten ist sehr viel Software entwickelt worden, die wir heute modernisieren und zukunftsfähig machen wollen. Domain-Driven Design (DDD) eignet sich hervorragend, um große Legacy-Systeme in Microservices zu zerlegen oder zu wartbaren Monolithen umzubauen. In diesem Transformationsprozess wird der fachliche Kern des Softwaresystems herausgearbeitet. Auf der Makro-Architektur-Ebene wird das System in unabhängige DDD-Module aufgeteilt. Auf der Mikro-Architektur-Ebene werden zusätzlich DDD-Muster eingesetzt, um den Code weiter zu strukturieren.   Dieses Buch kombiniert Anleitungen, Erkenntnisse und Beispiele aus der Beraterpraxis des Autorenteams. Es veranschaulicht, wie Techniken aus DDD und Refactorings verwendet werden können, um Softwaresysteme zu transformieren, die über Jahre gewachsen und möglicherweise ohne Architekturverständnis entwickelt wurden. Die Leser*innen lernen einen Prozess der Transformation kennen, den sie als Ganzes oder schrittweise in ihre Alltagspraxis übernehmen können, um die Wartbarkeit ihrer Legacy-Systeme effektiv und schnell zu verbessern. Sie erhalten: - einen detaillierten Einblick in DDD und die Verwendung der vielfältigen DDD-Techniken in der Praxis, - eine Anleitung, wie DDD eingesetzt werden kann, damit Legacy-Systeme wartbar bleiben oder wartbarer werden, - eine Anleitung, wie vorzugehen ist, falls eine Zerlegung der Monolithen und eine Neustrukturierung der Microservices geplant ist, - Argumente an die Hand, wann eine Zerlegung in Microservices für einen Monolithen sinnvoll ist und wann nicht. 

Dr. Carola Lilienthal ist Geschäftsfu?hrerin der WPS Workplace Solutions GmbH in Hamburg und verantwortet dort den Bereich Softwarearchitektur. Sie hat 1995 an der Universität Hamburg ihr Diplom in Informatik gemacht und dort zum Thema »Komplexität von Softwarearchitekturen« promoviert. Seit 2003 analysiert sie international im Auftrag ihrer Kunden die Architektur von Softwaresystemen und berät Entwicklungsteams, wie sie die Langlebigkeit ihrer Softwaresysteme verbessern können. Insgesamt hat sie mit ihrem Team u?ber dreihundert Softwaresysteme zwischen 30000 und 15 Mio. LOC in Java, C++, C#, ABAP, PHP und TypeScript untersucht. Besonders am Herzen liegt ihr die Ausbildung von Softwarearchitekten und Entwicklern, weshalb sie aktives Mitglied bei iSAQB, International Software Architecture Qualification Board, ist und ihr Wissen aus über 25 Jahren Softwareentwicklung regelmäßig auf Konferenzen, in Artikeln und bei Schulungen weitergibt. Henning Schwentner liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Softwarearchitekt, Berater, Trainer und Entwickler bei der WPS - Workplace Solutions GmbH aus. Seine Projekte sind Domain-Driven, agil und in Programmiersprachen wie Java und C#, aber auch ABAP geschrieben. Er gibt regelmäßig Workshops zum Thema Domain-Driven Design.mehr
Verfügbare Formate
BuchKartoniert, Paperback
EUR34,90
E-BookPDF1 - PDF WatermarkE-Book
EUR27,90
E-BookEPUBePub WasserzeichenE-Book
EUR27,90

Produkt

KlappentextÜber den Umbau von IT-Landschaften mit Domain-Driven Design - kompakter, tiefgehender Einblick in Domain-Driven Design (DDD) und die Verwendung der vielfältigen DDD-Techniken in der Praxis - Fokussierung auf Legacy-Systeme und Migration in Richtung gut strukturierter Monolithen und Microservices - Zusammenhang zwischen Transformation der Architektur und der TeamorganisationIn den letzten Jahrzehnten ist sehr viel Software entwickelt worden, die wir heute modernisieren und zukunftsfähig machen wollen. Domain-Driven Design (DDD) eignet sich hervorragend, um große Legacy-Systeme in Microservices zu zerlegen oder zu wartbaren Monolithen umzubauen. In diesem Transformationsprozess wird der fachliche Kern des Softwaresystems herausgearbeitet. Auf der Makro-Architektur-Ebene wird das System in unabhängige DDD-Module aufgeteilt. Auf der Mikro-Architektur-Ebene werden zusätzlich DDD-Muster eingesetzt, um den Code weiter zu strukturieren.   Dieses Buch kombiniert Anleitungen, Erkenntnisse und Beispiele aus der Beraterpraxis des Autorenteams. Es veranschaulicht, wie Techniken aus DDD und Refactorings verwendet werden können, um Softwaresysteme zu transformieren, die über Jahre gewachsen und möglicherweise ohne Architekturverständnis entwickelt wurden. Die Leser*innen lernen einen Prozess der Transformation kennen, den sie als Ganzes oder schrittweise in ihre Alltagspraxis übernehmen können, um die Wartbarkeit ihrer Legacy-Systeme effektiv und schnell zu verbessern. Sie erhalten: - einen detaillierten Einblick in DDD und die Verwendung der vielfältigen DDD-Techniken in der Praxis, - eine Anleitung, wie DDD eingesetzt werden kann, damit Legacy-Systeme wartbar bleiben oder wartbarer werden, - eine Anleitung, wie vorzugehen ist, falls eine Zerlegung der Monolithen und eine Neustrukturierung der Microservices geplant ist, - Argumente an die Hand, wann eine Zerlegung in Microservices für einen Monolithen sinnvoll ist und wann nicht. 

Dr. Carola Lilienthal ist Geschäftsfu?hrerin der WPS Workplace Solutions GmbH in Hamburg und verantwortet dort den Bereich Softwarearchitektur. Sie hat 1995 an der Universität Hamburg ihr Diplom in Informatik gemacht und dort zum Thema »Komplexität von Softwarearchitekturen« promoviert. Seit 2003 analysiert sie international im Auftrag ihrer Kunden die Architektur von Softwaresystemen und berät Entwicklungsteams, wie sie die Langlebigkeit ihrer Softwaresysteme verbessern können. Insgesamt hat sie mit ihrem Team u?ber dreihundert Softwaresysteme zwischen 30000 und 15 Mio. LOC in Java, C++, C#, ABAP, PHP und TypeScript untersucht. Besonders am Herzen liegt ihr die Ausbildung von Softwarearchitekten und Entwicklern, weshalb sie aktives Mitglied bei iSAQB, International Software Architecture Qualification Board, ist und ihr Wissen aus über 25 Jahren Softwareentwicklung regelmäßig auf Konferenzen, in Artikeln und bei Schulungen weitergibt. Henning Schwentner liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Softwarearchitekt, Berater, Trainer und Entwickler bei der WPS - Workplace Solutions GmbH aus. Seine Projekte sind Domain-Driven, agil und in Programmiersprachen wie Java und C#, aber auch ABAP geschrieben. Er gibt regelmäßig Workshops zum Thema Domain-Driven Design.
Details
Weitere ISBN/GTIN9783969107652
ProduktartE-Book
EinbandartE-Book
FormatEPUB
Format HinweisePub Wasserzeichen
FormatE101
Erscheinungsjahr2023
Erscheinungsdatum04.09.2023
Seiten312 Seiten
SpracheDeutsch
Dateigrösse17673 Kbytes
Artikel-Nr.12317665
Rubriken
Genre9201

Inhalt/Kritik

Leseprobe

1Einleitung: Komplexität beherrschen

Wenn man auf der grünen Wiese mit einem Softwareprojekt anfängt, macht alles Spaß und alles ist einfach. Die Entwickler reagieren blitzschnell auf neue Anforderungen. Die Anwender sind begeistert. Die Entwicklung geht in großen Schritten voran.

Über die Lebenszeit des Systems wird sich das ändern. Unweigerlich erhöht sich die Komplexität der Software. Diese ansteigende Komplexität führt zu höherer Fehleranfälligkeit, immer langsamerem Fortschritt und schlechterer Wartbarkeit. Und schließlich braucht es ein halbes Jahr, bis auch nur die kleinste Änderung in Produktion angekommen ist. Aus der blühenden grünen Wiese ist ein schlammiger, stinkender Acker geworden. »Altsystem«, »Legacy-Software«, »Big Ball of Mud«, »Monolith«, »Gummistiefelprojekt« sind die wenig schmeichelhaften Namen, mit denen diese Art von Systemen versehen werden.


»The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer.«

Bjarne Stroustrup


Aber es gibt Hoffnung! Auch diesen in die Jahre gekommenen Systemen kann Flexibilität, Fehlerrobustheit und Entwicklungsgeschwindigkeit zurückgegeben werden. Kernaufgabe ist dabei die Beherrschung (und Aufteilung) von Komplexität.
1.1Komplexität

Um einordnen zu können, wie mit Komplexität bei der Softwareentwicklung umgegangen werden kann, ist der Untertitel von Eric Evans´ Buch Domain-Driven Design ein guter Wegweiser: Tackling Complexity in the Heart of Software [Evans 2004]. Evans gibt uns das Versprechen, dass das von ihm beschriebene Vorgehen Komplexität in der Software(-entwicklung) reduziert oder zumindest handhabbar macht. Domain-Driven Design hilft dabei auf unterschiedlichen Ebenen. In Abbildung 1-1 sind die verschiedenen Aspekte von Komplexität, die uns bei der Softwareentwicklung begegnen, in Anlehnung an [Lilienthal 2008] und [Lilienthal 2019] zusammengefasst.

Abb. 1-1Komplexität und ihre Quellen

Im weiteren Verlauf werden wir sehen, dass die Grundlagen, die wir im ersten Teil des Buches einführen, Methoden und Heuristiken für bestimmte in Abbildung 1-1 aufgeführte Komplexitätsquellen anbieten. Wir werden diese Abbildung in den nächsten Abschnitten daher wiedersehen und sie Schritt für Schritt mit weiteren Informationen füllen.
1.2Herkunft der Komplexität: Problem- und Lösungsraum

Die Herkunftsdimension von Komplexität bei der Softwareentwicklung ist in Abbildung 1-1 auf der vertikalen Achse dargestellt. Diese Komplexität entsteht aus dem Wunsch, für eine Domäne eine Software zu bauen; also von der Domäne, einem Teil der wirklichen Welt (dem sog. Problemraum), zu einer Software mit passenden Geschäftsprozessen (in den sog. Lösungsraum) zu kommen. Wir haben somit zwei Quellen:
Problemraum: die Komplexität der Fachdomäne, für die das Softwaresystem gebaut wurde - die sogenannte probleminhärente Komplexität
Lösungsraum: die Komplexität, die in der Umsetzung bei der Modellierung, in der Architektur und bei der Verwendung der gewählten Technologie entsteht - die sogenannte lösungsabhängige Komplexität

In den letzten Jahrzehnten hat unser Berufsstand bei der Softwareentwicklung immer wieder die Erfahrung gemacht, dass es sehr schwer, wenn nicht gar unmöglich ist, die Komplexität im Problemraum am Anfang eines Projekts abzuschätzen und in einem Pflichtenheft niederzuschreiben. Deshalb dauern Projekte häufig viel länger als geplant, deshalb funktioniert das Wasserfallmodell so schlecht und deshalb sind agile Methoden so populär geworden. Richtig angewandt sind agile Methoden nämlich eine gute Hilfe, denn sie versuchen, die Komplexität im Problemraum in kleineren Häppchen Schritt für Schritt verschränkt mit der Umsetzung zu erfassen.
1.3Art der Komplexität: essenziell vs. akzidentell

In Abbildung 1-1 findet sich auf der horizontalen Dimension die Art der Komplexität mit den beiden Begriffen essenziell und akzidentell. Welche Anteile von Komplexität werden mit diesen beiden Begriffen beschrieben?

Haben wir das weltbeste und erfahrenste Team im Einsatz, dann können wir erwarten, dass wir eine gute Softwarelösung bekommen. Eine Softwarelösung, die eine für das Problem angemessene Komplexität aufweist. Ist die vom Entwicklungsteam gewählte Lösung komplexer als das eigentliche Problem, dann konnte das Entwicklungsteam die essenzielle Komplexität nicht richtig erfassen und die Lösung ist zu komplex, also nicht gut. Dieser Unterschied zwischen besseren und schlechteren Lösungen wird mit essenzieller und akzidenteller Komplexität bezeichnet.

Essenzielle Komplexität nennt man die Art von Komplexität, die im Wesen einer Sache liegt, also Teil seiner Essenz ist. Diese Komplexität lässt sich niemals auflösen oder durch einen besonders guten Entwurf vermeiden. Will man eine Software für eine komplexe Domäne bauen, für eine Domäne, bei der eine hohe Komplexität Teil ihres Wesens - ihrer Essenz - ist, so wird auch die Komplexität in der Software im Lösungsraum hoch ausfallen müssen. So hat eine Softwarelösung für ein Containerterminal eine größere essenzielle Komplexität als eine Software zur Verwaltung von Vereinsmitgliedern in einem Ruderclub.
1.3.1Quellen akzidenteller Komplexität
Akzidentelle Komplexität ist im Gegensatz zur essenziellen nicht notwendig. Sie entsteht aus folgenden Gründen:
aus Missverständnissen bei der Analyse der Fachdomäne, sodass uns die Fachdomäne komplexer erscheint, als sie eigentlich ist;
weil wir glauben, dass die Anwender für bestimmte Arbeitsschritte Unterstützung brauchen, obwohl sie eigentlich ganz anders arbeiten, und wir somit Sachen bauen, die keiner braucht;
weil wir uns für ein schlechtes Design und eine schlechte Architektur entscheiden bzw. Design und Architektur mit der Zeit durch Wartung, Änderung und Unkenntnis erodieren;
weil wir unpassende oder veraltete Technologie einsetzen, die ersetzt werden muss, oder weil wir die Technologie nicht so verwenden, wie es eigentlich vorgesehen war.

Wird bei der Entwicklung aus Unkenntnis oder mangelndem Überblick keine einfache Lösung gefunden, so ist das Softwaresystem unnötig komplex. Beispiele hierfür sind: Mehrfachimplementierungen, Einbau nicht benötigter Funktionalität und das Nichtbeachten softwaretechnischer Entwurfsprinzipien. Akzidentelle Komplexität kann von Entwicklern aber auch billigend in Kauf genommen werden, wenn sie z.B. gern neue, aber für das zu bauende Softwaresystem überflüssige Technologie ausprobieren wollen.
1.3.2Entscheidungsbereiche von Softwarearchitektur
Im Foundation Training des iSAQB - International Software Architecture Qualification Board (s. [iSAQB 2023]) -, der Basisausbildung für Softwarearchitekten, werden vier Bereiche definiert, die für die Entscheidungen über die Softwarearchitektur relevant sind: Anforderungsermittlung, Modellbildung, fachliche Architektur und technische Architektur. Diese vier Bereiche bzw. die in diesen Bereichen vorhandenen Methoden und Techniken lassen sich sehr gut auf Abbildung 1-1 anwenden.

Abb. 1-2Komplexität und Architektur

In Abbildung 1-2 können Sie sehen, dass Anforderungsermittlung und Modellbildung im Problemraum sowohl auf der essenziellen als auch auf der akzidentellen Seite ansetzen. Fachliche und technische Architektur wirken auf die essenzielle und akzidentelle Komplexität im Lösungsraum. Die Methoden und Techniken der Anforderungsermittlung, der Modellbildung, der fachlichen und technischen Architektur werden sowohl bei der Neuentwicklung als auch bei der Transformation von Legacy-Systemen eingesetzt, um die essenzielle Komplexität herauszudestillieren und möglichst viel akzidentelle Komplexität in unseren Systemen zu eliminieren (s. Abb. 1-3).

Abb. 1-3Einsatz von Methoden gegen Komplexität

Vollständig werden wir die akzidentelle Komplexität selbst mit den besten Methoden nicht auflösen können,...
mehr

Autor

Dr. Carola Lilienthal ist Geschäftsführerin der WPS Workplace Solutions GmbH in Hamburg und verantwortet dort den Bereich Softwarearchitektur. Sie hat 1995 an der Universität Hamburg ihr Diplom in Informatik gemacht und dort zum Thema »Komplexität von Softwarearchitekturen« promoviert. Seit 2003 analysiert sie international im Auftrag ihrer Kunden die Architektur von Softwaresystemen und berät Entwicklungsteams, wie sie die Langlebigkeit ihrer Softwaresysteme verbessern können. Insgesamt hat sie mit ihrem Team über dreihundert Softwaresysteme zwischen 30000 und 15 Mio. LOC in Java, C++, C#, ABAP, PHP und TypeScript untersucht. Besonders am Herzen liegt ihr die Ausbildung von Softwarearchitekten und Entwicklern, weshalb sie aktives Mitglied bei iSAQB, International Software Architecture Qualification Board, ist und ihr Wissen aus über 25 Jahren Softwareentwicklung regelmäßig auf Konferenzen, in Artikeln und bei Schulungen weitergibt. Henning Schwentner liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Softwarearchitekt, Berater, Trainer und Entwickler bei der WPS - Workplace Solutions GmbH aus. Seine Projekte sind Domain-Driven, agil und in Programmiersprachen wie Java und C#, aber auch ABAP geschrieben. Er gibt regelmäßig Workshops zum Thema Domain-Driven Design.