Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: MITP
- Kategorie: Wissenschaft und neue Technologien
- Serie: mitp Professional
- Sprache: Deutsch
- 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
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 209
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Tom Hombergs
Clean Architecture Praxisbuch
für saubere Software-Architektur und wartbaren Code
Übersetzung aus dem Englischen von Kathrin Lichtenberg
Impressum
Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN 978-3-7475-0816-9 1. Auflage 2024
www.mitp.de E-Mail: [email protected] Telefon: +49 7953 / 7189 - 079 Telefax: +49 7953 / 7189 - 082
© 2024 mitp Verlags GmbH & Co. KG
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Dieses E-Book verwendet das EPUB-Format und ist optimiert für die Nutzung mit Apple Books auf dem iPad von Apple. Bei der Verwendung von anderen Readern kann es zu Darstellungsproblemen kommen.
Der Verlag räumt Ihnen mit dem Kauf des E-Books das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine E-Books vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die E-Books mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert. Bei Kauf in anderen E-Book-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
Lektorat: Janina Vervost Fachkorrektorat: Tom Hombergs Sprachkorrektorat: Petra Heubach-Erdmann Covergestaltung: Christian Kalkert Coverbild: © Left / stock.adobe.com Satz: III-satz, Kiel, www.drei-satz.deelectronic publication: III-satz, Kiel, www.drei-satz.de
Vorwort
Das Paradies fürs Entwicklungsteam: Domänenlogik ist einfach zu testen, Infrastruktur und Technologie für Tests einfach zu simulieren (zu »mocken«) und es gibt eine ganz saubere Trennung zwischen Domänencode und technischem Code. Selbst die Migration von einer Technologie auf eine andere geht leicht von der Hand. Keine endlosen Diskussionen mehr, welcher Teil des Codes dieses verzwickte kleine Feature implementieren soll, das die Verkaufsleute schon der Fachabteilung versprochen haben. Dieses Paradies heißt »Clean Architecture«, und Tom wird Sie auf Ihrer Reise dorthin begleiten.
Seit einigen Jahren gibt es diese Clean Architecture unter verschiedenen Namen (etwa: Hexagonale Architektur, Ports-und-Adapter-Architektur, Zwiebelarchitektur). Dem Ganzen liegt eine ziemlich einfache Idee zugrunde: zwei konzentrische Kreise, die Domäne und Technik innerhalb der Software trennen. Abhängigkeiten fließen grundsätzlich nach innen, von der Technologie zur Domäne. Domänenklassen dürfen niemals Abhängigkeiten zu technischen Klassen haben.
Zu schade nur, dass die meisten der Originalquellen es versäumt haben, die Details der Umsetzung zu erklären, beispielsweise wie Packages und Code organisiert sein sollten. Toms Buch füllt diese Lücke perfekt aus. Anhand eines anschaulichen Beispiels führt Tom Sie (und Ihr Entwicklungsteam) zu einer ausgesprochen gut wartbaren und sauberen architektonischen Struktur.
Tun Sie sich selbst und Ihrem Entwicklungsteam einen Gefallen, geben Sie der Clean Architecture eine Chance. Ich verspreche Ihnen, dass Sie es nicht bereuen werden!
Gernot StarkeKöln, Juni 2023Pragmatischer Softwarearchitekt seit den 1990er-Jahren, Gründer von arc42, Mitgründer von iSAQB und Nerd
Mitwirkende
Über den Autor
Tom Hombergs ist Softwareentwickler, Autor und Simplicity Nerd. Komplexität ist sein Kryptonit, also zerlegt er komplexe Probleme stets in ihre Einzelteile, um sie zu verstehen. Das Ergebnis sind einfacher Code und einfache Texte, sei es in Artikeln auf seinem Blog, in seinen Büchern oder in Dokumentationen, die er für andere Entwickler schreibt. Tom arbeitet aktuell bei Atlassian in Sydney, wo er für die Developer Experience (DX) des Java Tech Stacks verantwortlich ist, der von Hunderten Entwicklern weltweit verwendet wird.
Über die Fachgutachter
Alexandros Trifyllis ist freiberuflicher Softwareentwickler mit 15-jähriger Erfahrung. Er war an großen Projekten im öffentlichen und privaten Sektor sowie auf EU-Ebene beteiligt.
Seine Interessenbereiche umfassen Backend-Entwicklung (Spring Boot), Frontend-Entwicklung (Angular) und verschiedene Architekturpraktiken (hexagonal/DDD). Außerdem mischt er sich gern in DevOps-Aufgaben ein (AWS, Terraform und Kubernetes). In den letzten Jahren hat er ein Interesse an DX und Developer Productivity Engineering (DPE) entwickelt sowie ganz allgemein darüber nachgedacht, wie man die Arbeit von Entwicklern einfacher und angenehmer gestalten kann.
Artem Gorbounov ist Java-Full-Stack-Entwickler mit einer Leidenschaft für saubere Architektur und fünfjähriger Industrieerfahrung. Momentan arbeitet er bei OneUp, wo er sich auf das Bauen robuster und skalierbarer Webanwendungen spezialisiert hat. Artem Gorbounov besitzt eine Amazon-Zertifizierung, die seine Expertise in Cloud-Computing-Technologien beweist. Er ist überzeugt, dass ein wahrer Full-Stack-Programmierer ein umfassendes Verständnis des ganzen technologischen Stacks haben sollte, von der Datenbank bis zur Infrastruktur, mit einer klaren Vorstellung von der Anwendungsarchitektur.
Dr. Gernot Starke ist Trainer und Berater für Softwarearchitektur, InnoQ-Fellow, Mitgründer von arc42 und iSAQB, Gründer von aim42, ehemaliger technischer Direktor des Sun Microsystems Object-Reality-Center und ein Nerd, der Bulletproof Coffee genießt.
Jonas Havers ist freiberuflicher Full-Stack-Softwareentwickler mit mehr als 15 Jahren Berufserfahrung bei internationalen E-Commerce-Unternehmen. Als Solution- und Anwendungsarchitekt hilft er Kunden, große Business-Softwaresysteme zu entwerfen und zu bauen, die es ihnen ermöglichen, schnell auf Änderungen zu reagieren und in ihrem Markt erfolgreicher zu werden. Er ist bewandert in einer Vielzahl von Werkzeugen, Methodologien und Programmiersprachen, darunter Java, Kotlin und JavaScript. Jonas erklärt, diskutiert und implementiert regelmäßig verschiedene Softwaredesigns und Softwarearchitekturen und teilt sein Wissen und seine Erfahrungen gern mit den Mitgliedern seines Projektteams sowie seinen Studenten als gefragter Gastdozent an Universitäten.
Jörg Gellien hilft Teams in einem innovativen Unternehmen, moderne, hochskalierbare Anwendungen zu entwerfen und zu entwickeln, um Geschäftsanforderungen gerecht zu werden. Er ist Experte für Softwarearchitektur und Java/Spring-Entwicklung. Starke Motivationen für seine Arbeit sind die Vorstellung von Ende-zu-Ende-Verantwortlichkeit für ein Produkt und die Benutzung von cloudbasierten Services.
Jo Vanthournout ist seit fast 20 Jahren Java-Entwickler und -Architekt. Er hatte das Glück, seine Karriere als Entwickler bei einem der ersten Extreme-Programming-Projekte in Belgien beginnen zu können. Seitdem versucht er, die Werte des agilen Entwickelns zu leben und weiterzuverbreiten. Jo Vanthournout hat lebhaftes Interesse an DDD und benutzt deren Prinzipien und Techniken täglich. Er wird nie der beste Entwickler im Team sein, doch man kann immer darauf vertrauen, dass er einen pragmatischen Überblick über die jeweilige Problemdomäne hat, gemeine Fragen stellt und die Teammitglieder an die Einhaltung der Teamwerte erinnert. Er hat eine wunderbare Frau und zwei Töchter. Wenn er nicht programmiert, dann läuft er durch den Wald, besucht Schlachtfelder des Zweiten Weltkriegs oder spielt Minecraft mit seinen Kindern.
K. Siva Prasad Reddy ist Softwarearchitekt mit mehr als 18 Jahren Erfahrung beim Bauen skalierbarer Softwaresysteme, vor allem mithilfe der Java-Plattform.
Er ist ein begeisterter Anhänger agiler Praktiken und verfolgt einen pragmatischen Ansatz bei Softwaredesign und -architektur. Seine Erkenntnisse und Gedanken kann man unter https://sivalabs.in verfolgen.
Lorenzo Bettini (https://www.lorenzobettini.it) ist Informatikdozent beim DISIA der Universität Florenz. Seine Forschung befasst sich mit dem Design, der Theorie und der Implementierung von Programmiersprachen mit IDE-Unterstützung.
Er hat mehr als 90 Forschungsartikel geschrieben, die bei internationalen Konferenzen und in internationalen Zeitschriften veröffentlicht wurden, ist Autor von zwei Ausgaben des Buches Implementing Domain-Specific Languages with Xtext and Xtend (Packt Publishing) sowie des Buches Test-Driven Development, Build Automation, Continuous Integration (with Java, Eclipse and friends) (Leanpub).
Maria Luisa Della Vedova ist eine leidenschaftliche Softwareentwicklerin, die sich der Schaffung sinnvoller und benutzerzentrierter Lösungen, dem kontinuierlichen Lernen und der Zusammenarbeit verschrieben hat, um einen positiven Einfluss auf das Leben anderer Menschen auszuüben.
Matt Penning unterstützt Unternehmen seit mehr als drei Jahrzehnten mit technischen Ratschlägen und Softwareentwicklung. Er ist bekannt für seine wohldefinierten und innovativen Architekturen, die reale Probleme lösen. Zurzeit arbeitet er als technischer Leiter bei Cisco Systems, Inc., wo er für Java-Microservice-Entwicklung, Softwarequalität und Entwicklerproduktivität zuständig ist.
Mike Davidson ist ein führender Entwickler und Anwendungsarchitekt. Er arbeitet mit Start-ups und Finanzinstituten in Neuseeland, Kanada und den USA zusammen, um ihnen zu helfen, wartbare, sauber strukturierte Software zu erstellen.
Octavian Nita befasst sich seit mehr als 18 Jahren beruflich und privat mit Java, wobei er von der Sprachimplementierung und Softwareautomatisierung inzwischen zu desktop- und webbasierten Anwendungen gekommen ist. Das macht ihm immer noch sehr viel Spaß.
Da er heutzutage in Brüssel lebt, hilft er den EU-Verwaltungsorganen dabei, mittels domänenzentrierter Architekturstile sogenannte »Enterprise-Anwendungen« zu implementieren.
Sven Woltmann ist schon seit den Anfangszeiten der Sprache Java-Entwickler. Er arbeitet als unabhängiger Entwickler, Trainer und Kursleiter und hat sich auf hochskalierbare Java-Enterprise-Anwendungen, Algorithmenoptimierung, sauberen Code und Clean Architecture spezialisiert. Mittels Videos, einem Newsletter und seinem Blog HappyCoders.eu teilt er sein Wissen gern mit anderen.
Thomas Buss ist IT-Berater bei codecentric in Deutschland. Er hilft Teams, die Komplexität von Softwareprodukten zu reduzieren und somit den Entwicklungsprozess zu beschleunigen. Sein Background liegt in der Sprache Java, aber er hat auch viel Freude daran, sich andere Paradigmen und Sprachen anzuschauen. Außerdem interessiert er sich für domänengetriebene Modellierung, serverlose Technologien und Möglichkeiten, den CO2-Fußabdruck von Systemen zu verkleinern. Darüber hinaus mag er Fernsehsendungen, die mit »Star« beginnen.
Vivek Ravikumar ist zurzeit technischer Mitarbeiter bei PayPal Indien und hat nahezu ein Jahrzehnt Erfahrungen bei der Entwicklung von Enterprise-Web-Anwendungen. Bei Seminaren und Vorlesungen an Bildungseinrichtungen und Universitäten in Indien hat er die Bedeutung und die besten Vorgehensweisen im Lifecycle der Softwareentwicklung demonstriert, Studenten betreut und Branchenwissen verbreitet.
In jüngster Zeit ist er bei Jakarta EE, MicroProfile und auf der Payara-Plattform zur Legende aufgestiegen, nachdem er sich den Spitzenplatz im ersten globalen Payara-Hackathon beim Bau einer Enterprise-Webanwendung gesichert hatte.
Wim Deblauwe ist freiberuflicher Java-Entwickler mit mehr als 20 Jahren Java-Erfahrungen. Er ist der Autor von Taming Thymeleaf und Practical Guide to Building an API Back End with Spring Boot. Außerdem hat er verschiedene Open-Source-Projekte gestartet bzw. an ihnen mitgearbeitet, wie etwa error-handling-spring-boot-starter und testcontainers-cypress.
Einleitung
Wenn Sie dieses Buch in die Hand genommen haben, dann machen Sie sich vermutlich Gedanken um die Software, die Sie entwickeln. Sie möchten nicht nur, dass Ihre Software die expliziten Anforderungen Ihrer Kunden erfüllt, sondern auch die implizite Anforderung der Wartbarkeit sowie Ihre eigenen Ansprüche hinsichtlich Struktur und Ästhetik.
Es ist schwer, diesen Anforderungen gerecht zu werden, da Softwareprojekte (oder Projekte ganz allgemein, wenn wir ehrlich sind) üblicherweise nicht so verlaufen wie geplant. Manager ziehen um das ganze Projektteam eine Deadline[1] , externe Partner bauen ihre APIs anders als versprochen und die Softwareprodukte, von denen wir abhängig sind, funktionieren nicht so, wie wir es erwarten.
Und dann ist da noch Ihre eigene Softwarearchitektur. Zu Anfang war sie so einfach. Alles war klar und schön. Dann zwang die Deadline Sie dazu, Abkürzungen zu nehmen. Die Abkürzungen sind nun alles, was von der Architektur geblieben ist, und es dauert länger und länger, neue Features abzuliefern.
Ihre von Abkürzungen belastete Architektur macht es schwer, auf eine API zu reagieren, die geändert werden musste, weil ein externer Partner Mist gebaut hat. Es scheint leichter, einfach Ihren Projektmanager vorzuschicken, um diesem Partner mitzuteilen, dass er die API abliefern soll, auf die Sie sich geeinigt hatten.
Inzwischen haben Sie vollständig die Kontrolle über die Situation verloren. Mit hoher Wahrscheinlichkeit wird eines der folgenden Dinge passieren:
Der Projektmanager ist nicht stark genug, um den Kampf gegen den externen Partner zu gewinnen.
Der externe Partner findet ein Schlupfloch in der Spezifikation der API, das ihm recht gibt.
Der externe Partner braucht weitere <hier Zahl einsetzen> Monate, um die API anzupassen.
All das führt zum selben Ergebnis, Sie müssen schnell Ihren Code ändern, weil die Deadline droht.
Sie fügen eine weitere Abkürzung ein.
Anstatt den Zustand Ihrer Softwarearchitektur durch äußere Umstände diktieren zu lassen, setzt dieses Buch darauf, dass Sie selbst die Kontrolle übernehmen. Sie erreichen dies, indem Sie eine Architektur erschaffen, die Ihre Software »soft«, also »weich« macht, im Sinne von »flexibel«, »erweiterbar« und »anpassbar«. Eine solche Architektur erlaubt es Ihnen problemlos, auf externe Faktoren zu reagieren und nimmt eine große Last von Ihren Schultern.
Das Ziel dieses Buches
Ich habe dieses Buch geschrieben, weil ich von der Praktikabilität der verfügbaren Ressourcen über domänenzentrierte Architekturstile enttäuscht war. Zu diesen Architekturstilen gehören Clean Architecture von Robert C. Martin und Hexagonal Architecture von Alistair Cockburn.
Viele Bücher und Online-Ressourcen beschreiben wertvolle Konzepte, aber nicht, wie man diese tatsächlich implementieren kann. Das liegt vermutlich daran, dass es mehr als eine Möglichkeit gibt, einen Architekturstil zu implementieren.
Mit einer praktischen Diskussion über das Herstellen einer Webanwendung im Stil einer Hexagonalen Architektur bzw. im »Ports-und-Adapter«-Stil versuche ich, diese Lücke zu füllen. Um dieses Ziel zu erreichen, demonstrieren die Codebeispiele und Konzepte in diesem Buch meine Interpretation der Implementierung einer Hexagonalen Architektur. Es gibt ganz sicher andere Interpretationen und ich erhebe auch nicht den Anspruch, dass meine die allgemeingültige Lösung ist.
Ich hoffe jedoch, dass die Konzepte in diesem Buch Ihnen eine gewisse Inspiration bieten, sodass Sie Ihre eigene Interpretation der Hexagonalen/Clean Architecture finden.
An wen sich dieses Buch richtet
Dieses Buch ist für Softwareentwickler aller Erfahrungsstufen gedacht, die sich mit dem Erstellen von Webanwendungen befassen.
Als Einsteiger oder Einsteigerin lernen Sie, wie Sie Softwarekomponenten und ganze Anwendungen auf saubere und wartbare Art und Weise entwerfen. Sie erfahren auch etwas darüber, wann Sie eine bestimmte Technik einsetzen können und sollten. Um wirklich den größten Nutzen aus diesem Buch zu ziehen, sollten Sie allerdings bereits einmal an der Erstellung einer Webanwendung mitgewirkt haben.
Als Entwicklerin und Entwickler mit größerer Erfahrung haben Sie Gelegenheit, die Konzepte aus dem Buch mit Ihrer eigenen Vorgehensweise zu vergleichen und hoffentlich einige davon in Ihren eigenen Entwicklungsstil zu integrieren.
Die Codebeispiele sind in Java und Kotlin geschrieben, aber alle Erörterungen lassen sich gleichermaßen auf andere objektorientierte Programmiersprachen anwenden. Falls Sie kein Java-Programmierer sind, aber objektorientierten Code in anderen Sprachen lesen können, ist alles gut. An den wenigen Stellen, an denen wir Java- oder Framework-Spezifika benötigen, werde ich diese erklären.
Die Beispielanwendung
Um einen thematischen roten Faden in diesem Buch zu haben, zeigen die meisten Codebeispiele Ausschnitte einer beispielhaften Webanwendung für Online-Überweisungen. Sie trägt den Namen »BuckPal«[2] .
Die BuckPal-Anwendung erlaubt es einem Benutzer, ein Konto zu registrieren, Geld zwischen Konten zu transferieren und die Aktivitäten auf dem Konto (Ein- und Auszahlungen) einzusehen.
Ich bin kein Finanzspezialist, also versuchen Sie nicht, den Beispielcode anhand seiner rechtlichen oder funktionalen Korrektheit zu bewerten. Bewerten Sie ihn lieber anhand seiner Struktur und seiner Wartbarkeit.
Der Fluch von Beispielanwendungen für Softwaretechnikbücher und Online-Ressourcen liegt darin, dass sie zu einfach sind, um tatsächlich die realen Probleme anzusprechen, mit denen Sie sich jeden Tag auseinandersetzen müssen. Andererseits muss eine Beispielanwendung einfach genug bleiben, um die diskutierten Konzepte effektiv zu vermitteln.
Ich hoffe, das richtige Gleichgewicht zwischen »zu einfach« und »zu komplex« gefunden zu haben, wenn wir die Anwendungsfälle der BuckPal-Anwendung in diesem Buch diskutieren.
Der Code der Beispielanwendung ist auf GitHub zu finden.[3]
Treten Sie in Kontakt
Falls Sie etwas zu diesem Buch sagen möchten, würde ich mich freuen, von Ihnen zu hören. Schreiben Sie mir direkt eine E-Mail an [email protected] oder auf Twitter über @TomHombergs.
Sollte es zu diesem Buch bereits eine Errata-Liste geben, ist sie unter www.mitp.de/0814 zu finden.
[1] Das Wort »Deadline« stammt angeblich aus dem 19. Jahrhundert und beschrieb eine Linie, die um ein Gefängnis oder Gefangenenlager gezogen wurde. Ein Gefangener, der diese Linie überquerte, wurde erschossen. Behalten Sie das im Hinterkopf, wenn wieder einmal jemand eine »Deadline« zieht! Im Deutschen gibt es den viel harmloseren – wenn auch bürokratischer klingenden – Begriff des »Fälligkeitstermins«. Falls Sie gern gefährlicher leben, können Sie auch von einer »Galgenfrist« sprechen – das ist die kurze Zeit, die einem noch bis zu einem unangenehmen Ereignis (dem Gang zum Galgen) bleibt.
[2] Eine schnelle Online-Suche hat ergeben, dass ein Unternehmen namens PayPal meine Idee gestohlen und sogar einen Teil des Namens kopiert hat. Scherz beiseite: Versuchen Sie einmal, einen Namen zu finden, der so ähnlich ist wie »PayPal«, aber nicht der Name eines existierenden Unternehmens ist. Zum Schreien komisch!
[3] Das BuckPal-GitHub-Repository: https://github.com/thombergs/buckpal.
Kapitel 1: Wartbarkeit
Dieses Buch dreht sich um Softwarearchitektur. Eine der Definitionen von Architekturist 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
