Clean Architecture Praxisbuch (eBook)

für saubere Software-Architekturen und wartbaren Code. Mit Codebeispielen in Java

Tom Hombergs (Autor)

eBook Download: EPUB

2024 | 1. Auflage
184 Seiten
MITP Verlags GmbH & Co. KG
978-3-7475-0816-9 (ISBN)

Infos

Best Practices für die Entwicklung von anpassungsfähiger Software Lernen Sie neue Konzepte kennen und verbinden Sie diese mit Ihrem eigenen Softwareentwicklungsstil Entwickeln Sie ein Mindset für bewusste Architekturentscheidungen Der Weg zu wartbarer Software Eine wartungsfreundliche Architektur ist der Schlüssel, um Entwicklungsaufwand und -kosten niedrig zu halten. Dieses Buch vermittelt Ihnen alle notwendigen Fähigkeiten und Kenntnisse, um wartbare und langlebige Software zu entwickeln, ohne Vorkenntnisse vorauszusetzen. Domänen-zentrierte Architektur in der Praxis Dieser umfassende Leitfaden zeigt die Vorteile domänen-zentrierter Softwarearchitektur auf - angelehnt an Robert C. Martins Clean Architecture und Alistair Cockburns hexagonale Architektur. Anhand zahlreicher Beispiele erfahren Sie, wie Sie eine hexagonale Architektur in Ihrem Code abbilden können. Sie lernen verschiedene Strategien für das Mapping zwischen den Schichten einer hexagonalen Architektur kennen und erfahren, wie Sie die Architekturelemente zu einer Anwendung zusammensetzen. Komplexe Konzepte leicht verständlich erklärt Mit anschaulichen Erläuterungen und anhand zahlreicher Codebeispiele schafft dieses Buch ein tiefes und praxistaugliches Verständnis des hexagonalen Architekturstils. So sind Sie perfekt darauf vorbereitet, wartbare Anwendungen zu erstellen, die Zeit und Geld sparen. Aus dem Inhalt: Wartbare Software entwickeln Schwachstellen der herkömmlichen Schichtenarchitektur identifizieren Code sauber strukturieren Umkehren von Abhängigkeiten (Dependency Inversion) SOLID-Prinzipien für die hexagonale Architektur Use Cases implementieren Testmethoden für einzelne Architekturelemente Mapping-Strategien Architekturgrenzen durchsetzen Zahlreiche Codebeispiele in Java

Tom Hombergs ist Softwareentwickler, Autor, und Simplicity Nerd, der es liebt, Dinge zu vereinfachen. Aktuell arbeitet er bei Atlassian in Sydney, Australien, wo er für die Developer Experience der dort genutzten Technologie-Stacks verantwortlich ist.

Textauszug

Kapitel 1:
Wartbarkeit

Dieses Buch dreht sich um Softwarearchitektur. Eine der Definitionen von Architektur ‌‌ist die Struktur eines Systems oder Prozesses. In unserem Fall ist es die Struktur eines Softwaresystems.

Architektur ist das Entwerfen dieser Struktur mit einem Zweck. Sie gestalten Ihr Softwaresystem bewusst so, dass es bestimmte Anforderungen erfüllt. Es gibt funktionale Anforderungen, die eine Software erfüllen muss, um einen Nutzen für ihre Benutzer zu haben. Ohne Funktionalität ist Software wertlos, da sie keinen Nutzen besitzt.

Außerdem gibt es Qualitätsanforderungen‌ (auch nichtfunktionale Anforderungen‌ genannt), die eine Software erfüllen sollte, um von ihren Benutzern, Entwicklern und anderen Stakeholdern als qualitativ hochwertig betrachtet zu werden. Eine solche Qualitätsanforderung ist die Wartbarkeit‌.

Was würden Sie sagen, wenn ich behauptete, dass Wartbarkeit als Qualitätsmerkmal in gewisser Weise viel wichtiger ist als die Funktionalität und Sie die Wartbarkeit beim Entwurf von Software daher über alles andere stellen sollten? Nachdem wir die Wartbarkeit als wichtige Qualität etabliert haben, werden wir im Rest des Buches untersuchen, wie wir diese Wartbarkeit verbessern können, indem wir die Konzepte von Clean Architecture und Hexagonaler Architektur anwenden.

1.1  Was bedeutet Wartbarkeit überhaupt?

‌Bevor Sie mich für verrückt erklären und versuchen, das Buch zurückzugeben, lassen Sie mich Ihnen erklären, was ich mit Wartbarkeit meine.

Wartbarkeit ist nur eine der vielen Qualitätsanforderungen, die potenziell eine Softwarearchitektur ausmachen. Ich habe ChatGPT nach einer Liste von Qualitätsanforderungen gefragt und folgendes Ergebnis erhalten:

• Skalierbarkeit

• Flexibilität

• Wartbarkeit

• Sicherheit

• Zuverlässigkeit

• Modularität

• Performance

• Interoperabilität

• Testbarkeit

• Kosteneffizienz

Und das ist nur eine kleine Auswahl.[1]

Als Softwarearchitekten entwerfen Sie Ihre Software so, dass sie die Qualitätsanforderungen erfüllt, die für die Software am wichtigsten sind. Für eine Trading-Anwendung mit hohem Durchsatz würden Sie sich zum Beispiel auf Skalierbarkeit und Zuverlässigkeit konzentrieren. Befasst sich die Anwendung mit persönlichen Informationen in Deutschland, müsste die Sicherheit an erster Stelle stehen.

Ich glaube, dass es falsch ist, die Wartbarkeit mit den restlichen Qualitätsanforderungen in einen Topf zu werfen, da Wartbarkeit etwas Besonderes ist. Ist eine Software wartbar, dann bedeutet dies, dass sie leicht zu ändern ist. Ist sie leicht zu ändern, dann ist sie flexibel und vermutlich auch modular. Wahrscheinlich ist sie auch kosteneffizient, da leichte Änderungen gleichbedeutend sind mit günstigen Änderungen. Ist sie wartbar, kann man sie vermutlich weiterentwickeln, sodass sie skalierbar, sicher, zuverlässig und performant ist, wenn sich das alles als notwendig erweisen sollte. Man kann die Software so verändern, dass sie mit anderen Systemen interoperabel wird, weil dies leicht zu ändern ist. Und schließlich impliziert die Wartbarkeit auch eine Testbarkeit, da wartbare Software mit hoher Wahrscheinlichkeit aus kleineren und einfacheren Komponenten besteht, die das Testen erleichtern.

Sie erkennen sicher, was ich hier gemacht habe. Ich habe die KI nach einer Liste von Qualitätsanforderungen gefragt und diese dann alle wieder auf Wartbarkeit zurückgeführt. Mit ähnlich plausiblen Argumenten könnte ich vermutlich noch viel mehr Qualitätsanforderungen an Wartbarkeit koppeln. Das ist natürlich ein bisschen vereinfacht, aber im Kern stimmt es: Wenn die Software wartbar ist, dann ist es einfacher, sie in alle Richtungen weiterzuentwickeln, funktional und nichtfunktional. Und wir alle wissen, dass Änderungen im Leben eines Softwaresystems unausweichlich sind.

1.2  Wartbarkeit führt zu Funktionalität

Kommen wir zurück zu meiner Behauptung vom Anfang dieses Kapitels, dass Wartbarkeit wichtiger ist als Funktionalität‌‌.

Fragen Sie einen Produktmenschen, was an einem Softwareprojekt am wichtigsten ist, dann wird er oder sie Ihnen sagen, dass der Wert, den die Software den Benutzern bietet, die wichtigste Sache ist. Mit Software, die ihren Benutzern keinen Wert bietet, ist kein Geld zu verdienen. Und ohne zahlende Benutzer gibt es kein funktionierendes Geschäftsmodell, das das wesentliche Maß für den Erfolg im Geschäftsleben ist.

Die Software muss also einen Wert bieten. Dies darf sie aber nicht auf Kosten der Wartbarkeit tun.[2] Denken Sie einmal darüber nach, wie viel effizienter und befriedigender es ist, Funktionalität zu einem Softwaresystem hinzuzufügen, das leicht zu ändern ist, als zu einem, bei dem Sie sich zeilenweise durch den Code kämpfen müssen! Ich bin mir ziemlich sicher, dass auch Sie schon einmal an einem dieser Softwareprojekte mitgearbeitet haben, bei denen es so viel überflüssigen Kram im Code gibt, dass es Tage oder Wochen dauert, um ein Feature zu entwickeln, das eigentlich nur ein paar Stunden zur Fertigstellung brauchen sollte.

Entsprechend ist Wartbarkeit also eine entscheidende Stütze für die Funktionalität. Schlechte Wartbarkeit bedeutet, dass Änderungen in der Funktionalität mit der Zeit immer teurer werden, wie Abbildung 1.1 zeigt:

Abb. 1.1: Ein wartbares Softwaresystem verursacht über seine Lebenszeit geringere Kosten als ein nicht so gut wartbares Softwaresystem.

In einem weniger gut wartbaren Softwaresystem werden Änderungen an der Funktionalität schon bald so teuer, dass jede Änderung ein Ärgernis wird. Die Produktleute beschweren sich bei den Entwicklern über die Kosten der Änderungen. Die Entwickler verteidigen sich wiederum damit, dass die Auslieferung neuer Features immer eine höhere Priorität hatte als die Verbesserung der Wartbarkeit. Mit zunehmenden Änderungskosten steigt auch die Wahrscheinlichkeit von Konflikten.

Wartbarkeit ist ein Friedensstifter. Sie ist umgekehrt proportional zu den Kosten von Änderungen und daher auch zur Wahrscheinlichkeit eines Konflikts. Haben Sie schon einmal darüber nachgedacht, die Wartbarkeit eines Softwaresystems zu verbessern, nur um einen Konflikt zu vermeiden? Ich denke, das allein ist schon eine gute Investition.

Was ist jedoch mit den großen Softwaresystemen, die trotz ihrer schlechten Wartbarkeit ‌erfolgreich sind? Es stimmt, dass es kommerziell erfolgreiche Softwaresysteme auf dem Markt gibt, die kaum gewartet werden können. Ich habe an Systemen gearbeitet, bei denen das Hinzufügen eines einzigen Feldes zu einem Formular ein Projekt war, das Wochen an Entwicklerzeit kostete – und der Kunde hat meinen geforderten Stundensatz bezahlt, ohne mit der Wimper zu zucken.

Diese Systeme fallen üblicherweise in eine von zwei Kategorien (manchmal auch in beide):

• Sie sind am Ende ihres Lebens, sodass nur noch ausgesprochen selten Änderungen an ihnen vorgenommen werden.

• Sie werden von einem finanziell gut aufgestellten Unternehmen gestützt, das bereit ist, Geld in das Problem zu stecken.

Selbst wenn ein Unternehmen viel Geld aufwenden kann, erkennt es normalerweise, dass es die Wartungskosten reduzieren könnte, indem es in die Wartbarkeit investiert. Üblicherweise sind in solchen Unternehmen daher bereits Initiativen auf dem Weg, um die Software besser wartbar zu machen.

Sie sollten sich immer um die Wartbarkeit der Software sorgen, die Sie entwickeln, damit diese nicht zu dem gefürchteten Big Ball of Mud‌ (einer großen Matschkugel) degeneriert. Falls Ihre Software jedoch nicht in eine der zwei genannten Kategorien fällt, müssen Sie sich sogar noch mehr Sorgen um sie machen.

Heißt das, Sie brauchen viel Zeit, um eine wartbare Architektur zu planen, bevor Sie überhaupt mit dem Programmieren beginnen? Müssen Sie ein Big Design Up Front (BDUF)‌ – eine vorher festgelegte Architektur – schaffen, was oft mit der Wasserfall-Methode gleichgesetzt wird?! Nein, das müssen Sie nicht. Aber Sie müssen zumindest ein bisschen was an Architektur planen (vielleicht sollten wir dies dann Some Design Up Front bzw. SDUF nennen?), um den Samen der Wartbarkeit in die Software einzupflanzen, der es Ihnen erleichtern dürfte, die Architektur mit der Zeit in die gewünschte Richtung zu entwickeln.

Teil dieses Vorab-Designs ist die Wahl eines Architekturstils‌, der den Rahmen für die Software definiert, die Sie entwickeln. Dieses Buch wird Ihnen helfen zu entscheiden, ob eine Clean Architecture – oder Ports-und-Adapter-/Hexagonale-Architektur – für Ihren Kontext eine gute Entscheidung ist.

1.3  Wartbarkeit erzeugt Entwicklerfreude

‌Würden Sie als Entwicklerin oder Entwickler lieber an Software arbeiten, bei der Änderungen einfach sind, oder an Software, bei der Änderungen schwer sind? Nicht antworten, es ist eine rhetorische Frage!

Abgesehen vom direkten Einfluss auf die Änderungskosten hat Wartbarkeit ‌noch einen weiteren Vorteil: Sie macht Entwickler glücklich (oder zumindest macht sie sie weniger traurig – je nachdem, wie das aktuelle Projekt gerade läuft).

Der Begriff, mit dem ich dieses Glück beschreiben möchte, lautet Developer Joy‌, also quasi Entwicklerfreude‌. Man...

Produkt-Details

• Erscheint lt. Verlag: 23.5.2024
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge
• ISBN-10: 3-7475-0816-2 / 3747508162
• ISBN-13: 978-3-7475-0816-9 / 9783747508169