Zukunftssichere Architektur: So bauen Sie monolithische Anwendungen zu komponentenorientierten um
()
About this ebook
Nur leider gibt es viele Programme, die wunderbar ihren Dienst verrichten, neuen Anforderungen aber angepasst werden müssen. Eine Neuentwicklung will der Kunde nicht bezahlen, also muss man aus dem, was vorliegt, das beste machen.
Architekturspezialist Ralf Westphal zeigt Ihnen in diesem Buch, wie Sie vorgehen, wenn Sie so eine Anwendung weiterentwickeln müssen. Wartbarkeit ist das zentrale Thema. Und die erreicht man durch Auftrennung von Monolithen zu komponentenorientierten Anwendungen. Aber wie gehen Sie dabei vor? In Beispielen führt Sie Ralf Westphal Schritt für Schritt durch einen Prozess, an dessen Ende eine Anwendung steht, die sich aus vielen Komponenten zusammensetzt. Jede der Komponenten kann nun ausgetauscht werden, ohne das Gesamtsystem in Mitleidenschaft zu ziehen.
Einleitend erklärt der Autor auch noch in zwei Grundlagenartikeln, warum Regeln bei der Implementierung nur Vorteile brauchen und warum die Komponentenorientierung so viele Vorteile mit sich bringt.
Related to Zukunftssichere Architektur
Related ebooks
Moderne Datenzugriffslösungen mit Entity Framework 6 Rating: 0 out of 5 stars0 ratingsTechnische Schulden: Identifizierung, Dokumentation und Management Rating: 0 out of 5 stars0 ratingsKnigge für Softwarearchitekten Rating: 0 out of 5 stars0 ratingsWindows-8-Apps für C#-Entwickler: Design-Guidelines, Anleitungen, Best Practices Rating: 0 out of 5 stars0 ratingsAgile Architektur mit .NET - Grundlagen und Best Practices Rating: 0 out of 5 stars0 ratingsGlossar Agilität: kurz - knapp - klar Rating: 0 out of 5 stars0 ratingsBessere Softwareentwicklung mit DevOps Rating: 0 out of 5 stars0 ratingsAgile Softwareentwicklung: Ein Leitfaden für Manager Rating: 0 out of 5 stars0 ratingsKnigge für Softwarearchitekten. Reloaded Rating: 0 out of 5 stars0 ratingsLogging: Schnelleinstieg Rating: 0 out of 5 stars0 ratingsGeschäftsprozesse im Projektmanagement: Best Practices der Implementierung Rating: 0 out of 5 stars0 ratingsProjektmanagement: Grundlagen, Methoden und Techniken Rating: 0 out of 5 stars0 ratingsEffekte-Praxis im Tonstudio: Einsteiger-Kurs mit theoretischen und praktischen Erläuterungen zur Effekt-Anwendung Rating: 0 out of 5 stars0 ratingsDer Meistermoderator: Das Handbuch für Personalentwickler, Teamleiter, Trainer und Mediatoren Rating: 0 out of 5 stars0 ratingsInnovationsmanagement: Die wichtigsten Methoden Rating: 0 out of 5 stars0 ratingsPraxis der Projektplanung: Projektmanagement konkret Rating: 0 out of 5 stars0 ratingsPraxis der Projektorganisation: Projektmanagement konkret Rating: 0 out of 5 stars0 ratingsMeine erste App Rating: 0 out of 5 stars0 ratingsSharePoint Kompendium - Bd. 13 Rating: 0 out of 5 stars0 ratingsDas Franzis Starterpaket Arduino Leonardo: Das Handbuch für den Schnelleinstieg Rating: 0 out of 5 stars0 ratingsPraxis der Projektkostenplanung: Projektmanagement konkret Rating: 0 out of 5 stars0 ratingsDAS PROJEKTERFOLG-HANDBUCH: Wie man mit neuer Baukultur erfolgreich bauen würde - Band 1 Basis Rating: 0 out of 5 stars0 ratingsLeitfaden für Architekten und Planer: Führung und Koordination von Bauprojekten Rating: 0 out of 5 stars0 ratingsMarketing-Routenplaner: Strategien effizient erarbeiten Rating: 0 out of 5 stars0 ratingsIch - Chef: Leitfaden für Existenzgründer Rating: 0 out of 5 stars0 ratingsGanzheitliches Projektmanagement Rating: 0 out of 5 stars0 ratingsBrandschutz: das kompakte Handbuch für Architekten Rating: 0 out of 5 stars0 ratingsVon zu Hause aus Geld verdienen!: Ein Leitfaden Rating: 0 out of 5 stars0 ratingsErfolgreiche Einführung neuer Pozessmodelle: Ihr Praxis-Leitfaden! Rating: 0 out of 5 stars0 ratings
Technology & Engineering For You
Der perfekte Fahrrad Mechaniker: Wartung, Reparatur, Pflege - mit Videos Rating: 0 out of 5 stars0 ratingsPanzerketten: Die Gleisketten der deutschen Kettenfahrzeuge des Zweiten Weltkrieges Rating: 5 out of 5 stars5/5Piano ohne Noten: Einführung ins freie Spielen auf Klavier und Keyboard Rating: 0 out of 5 stars0 ratingsHochfrequenz-Messpraxis: Zweckmäßige und kostengünstige Messverfahren für Ausbildung, Labor und Hobby Rating: 0 out of 5 stars0 ratingsCAD-Konstruktion Schritt für Schritt: Der Praxisguide für Einsteiger Rating: 0 out of 5 stars0 ratingsDie ultimative FRITZ!Box Bibel - Das Praxisbuch 2. aktualisierte Auflage - mit vielen Insider Tipps und Tricks - komplett in Farbe Rating: 0 out of 5 stars0 ratingsElektrokonstruktion: Elektrotechnik und Automation Rating: 0 out of 5 stars0 ratingsDas ultimative Sprachenlernbuch: Lernen Sie eine Sprache auf Profi-Niveau in 1 Jahr! Rating: 0 out of 5 stars0 ratingsMessmittelmanagement und Kalibrierung: Edition 2020 Rating: 5 out of 5 stars5/5Türöffnung Rating: 0 out of 5 stars0 ratingsHypnotische Trance als therapeutische Chance: > aus den Erfahrungen eines ganzheitlich arbeitenden Heilpraktikers < Rating: 0 out of 5 stars0 ratingsDie tägliche Mentaldusche: Eine inspirierende Reise zu dir selbst Rating: 0 out of 5 stars0 ratingsSpracherkennung für Autoren Rating: 0 out of 5 stars0 ratingsLegendary Loudspeakers: Die besten Lautsprecher der Welt Rating: 0 out of 5 stars0 ratingsBike-Reparatur & Wartung: Funktion, Einstellung, Pflege, Instandsetzung Rating: 0 out of 5 stars0 ratingsEinheiten im Lösch- und Hilfeleistungseinsatz: Die praktische Anwendung der FwDV 3 Rating: 0 out of 5 stars0 ratingsKanban für Anfänger: Grundlegendes über den Einsatz von Kanban in der Industrie und der Softwareentwicklung Rating: 0 out of 5 stars0 ratingsDrohnen selber bauen & tunen: Ohne Vorkenntnisse: Drohne, Quadrocopter, Multicopter: Schritt für Schritt selbst gebaut. Rating: 0 out of 5 stars0 ratingsPraktische Autoprüfung: Praktische Fahrprüfung Kategorie B Rating: 0 out of 5 stars0 ratingsOszilloskop und Spektrumanalysator: Kompendium Messtechnik und Sensorik, Teil 5 Rating: 5 out of 5 stars5/5Rennrad. Reparaturen unterwegs Rating: 0 out of 5 stars0 ratingsMit dem Fahrrad ins Büro: Alles, was Fahrradpendler wissen sollten Rating: 0 out of 5 stars0 ratingsFührung und Stabsarbeit trainieren Rating: 0 out of 5 stars0 ratingsGrundlagen abwehrender Brandschutz: Feuerwehrwissen für Architekten, Brandschutzplaner und Ingenieure Rating: 0 out of 5 stars0 ratings
Reviews for Zukunftssichere Architektur
0 ratings0 reviews
Book preview
Zukunftssichere Architektur - Ralf Westphal
EDITORIAL
Im Wandel liegt die Kraft
Fasst man die zentrale Botschaft der Softwarearchitekten gleich welcher Schule zusammen, könnte sie folgendermaßen lauten:
Monolithische Anwendungen sind tot. Lang lebe die komponentenorientierte Architektur.
So einfach sich diese Botschaft auch anhört, steckt doch in ihr die Erfahrung mit alten und neuen Systemen. Erst dank der Verteilung von Funktionalität auf verschiedene voneinander getrennte Komponenten ist es möglich, auf Forderungen der Kunden und der Entwickler einzugehen.
Erweiterbarkeit: Software lebt. Sie muss sich den sich verändernden Anforderungen anpassen können. rst komponentenorientierte Systeme ermöglichen das auf einfache Weise.
Testbarkeit: Die Qualität einzelner Teile soll durch automatische Tests gesichert werden, auch oder gerade wenn an anderer Stelle umgebaut wird.
Refaktorisierbarkeit: Wer erweitert oder umbaut, der muss Teile der Software verändern. Je feingranula-rer dann die Struktur ist, umso weniger muss verändert werden, was nicht nur Zeit und Geld spart, sondern auch die Qualität nicht verringert:
Dieses DevBook soll Ihnen zeigen, wie Sie Architekturen aufstellen, die auch morgen noch Bestand haben, weil sie sich gegen Veränderungen nicht sperren. Zuerst einmal ist es wichtig, strikte Regeln einzuführen, die später dafür sorgen, dass leicht umgebaut werden kann. Dazu zählen Schnittstellen: Wer Schnittstellen sauber aufstellt, kann einzelne Komponenten ersetzen, ohne dass das System in Mitleidenschaft gezogen wird. Solche Schnittstellen sollten durch automatische Tests gesichert werden. Wer die Schnittstellen durch solche Tests komplett abdeckt, kann sich sicher sein, dass bei einer Veränderung alles noch geht.
Diese Vorbemerkungen legen den Grundstock für das zentrale Thema des Buchs: Umbau einer vorhandenen monolithischen Anwendung. Wie gehen Sie dabei vor? Wo fangen Sie an? Schließlich haben Sie es mit einem Wust an Klassen und Methoden zu tun, die Sie eigentlich alle verstehen müssten.
Aber Ralf Westphal nimmt Sie an die Hand und zeigt Ihnen schrittweise, wie Sie aus der Chaos-Struktur eine sauber strukturierte Anwendung bauen. Abhängigkeiten spielen dabei eine große Rolle. Erst wenn Sie verstanden haben, wer von wem etwas braucht, können Sie den Fitz aufdröseln.
Zum Schluss kommt eine Anwendung heraus, die nicht nur durch ihren Aufbau sehr schnell verstehbar ist. Sie ist auch gleich für künftige Anforderungen oder Änderungen bestens gerüstet.
Beim Zerschneiden helfen - wie oben schon erwähnt - immer wieder Unit-Tests, die Schnittstellen absichern. Diese aber in einer monolithischen Anwendung einzuführen, scheint auf den ersten Blick aussichtslos. Aber auch hier weiß Ralf Westphal Rat und zeigt Ihnen, wie Sie dabei vorgehen.
Viel Spaß beim Lesen und Studieren
Tilman Börner
Chefredakteur dotnetpro
Inhalt
Methodik des Softwarebaus: Mehr Regeln wagen
Wie ein Hausbau braucht auch die Entwicklung von Software Konventionen, um Qualität erreichen zu können.
Semantische Verträge: Doppelt genäht hält besser
Wer seine Software als Komponenten entwickelt, hat beim Outsourcing die Nase vorn.
Eine Architektur für Legacy-Code 1: Alter Code neu gebaut
Sie sollen eine Software auf das .NET Framework 3.5 migrieren. Dabei soll das Projekt auch architektonisch fit für die Zukunft werden.
Eine Architektur für Legacy-Code 2: Vom IST zum SOLL
Legacy-Code muss nicht vom Mainframe stammen. Auch .NET-1.0-Code gilt bereits als Vermächtnis
von früher. Gehen Sie bei einer Migration systematisch vor!
Eine Architektur für Legacy-Code 3: Landkarten zeichnen
Mit den entsprechenden Werkzeugen ist es kein Problem, sich unbekanntem Code zu nähern.
Eine Architektur für Legacy-Code 4: Geschafft!
Im letzten Teil der Serie formen Sie mithilfe dieser Erkenntnisse ein neues Innenleben für die Software. Dabei machen Sie diese gleich fit für künftige Anpassungen.
Bestehende monolithische Anwendungen für Unit-Tests aufbereiten: Den Sumpf trockenlegen
Wer Software schreibt, sollte sie sofort auch selbst testen. Aber nicht irgendwie, sondern automatisiert mit Unit-Tests.
codekicker: Fragen und Antworten zur Architektur
Die wichtigsten Fragen und Antworten zur Softwarearchitektur aus der Wissensbörse codekicker.de.
Eine Monolith-Anwendung für Unit-Tests aufbereiten: Ein Sumpf wird grün
Eine bestehende monolithische Anwendung mit Unit-Tests nachzurüsten ist möglich. Separate Komponenten und Kontrakte - und schon sind Unit-Tests machbar.
Imprint
Zukunftssichere Architektur
Ralf Westphal
published by: epubli GmbH, Berlin, www.epubli.de
Copyright: © NMG
ISBN: 978-3-8442-2272-2
centerMethodik des Softwarebaus
Mehr Regeln wagen
Wie beim Hausbau braucht auch die Entwicklung von Software Konventionen, um Qualität erreichen zu können. Leider gibt es derzeit davon zu wenig. Mehr Konventionen würden den Entwickler besser leiten, ihm Arbeit und Entscheidungen abnehmen sowie mehr Zeit verschaffen, sich um das eigentliche Problemfeld der Software zu kümmern.
Stellen Sie sich vor, zwei einander unbekannte Softwareentwickler kommen über ihre Projekte ins Gespräch. Was würden sie wohl für Gemeinsamkeiten in der Realisierung ihrer Applikationen feststellen? Beide könnten für dieselbe Plattform entwickeln: Windows und .NET Framework; beide könnten an einer Anwendung derselben Art arbeiten, zum Beispiel eine Desktop- oder Webanwendung; beide könnten Daten in einer relationalen Datenbank speichern.
Und weiter? Sicherlich unterscheiden sich die Problemdomänen, an denen die Entwickler arbeiten. Der eine könnte eine CRM-Software und der andere Immobilienverwaltung schreiben. Sind also nicht mehr Gemeinsamkeiten bei zwei Softwareanwendungen zu erwarten?
Ein paar mögen noch unterhalb der Bewusstseinsschwelle liegen. Sie sind so natürlich, dass die beiden Softwareentwickler sie nicht für erwähnenswert halten. Zum Beispiel programmieren sie beide objektorientiert, zeichnen UML-Diagramme und halten die Normalisierung einer Datenbank für wichtig. Und natürlich haben ihre Anwendungen dieselbe Grundstruktur: Sie bestehen aus einer Benutzeroberfläche, greifen auf Infrastruktur zu und implementieren eine problemdomänenspezifische Logik.
Auf der Oberfläche der Anwendungen würde ein Laie sicherlich grundsätzlich dieselben Steuerelemente finden: Eingabefelder, Menüs, Schaltflächen, Tabellen. Aber darunter? Ist jenseits von Objektorientierung und einer groben Dreigliederung des Codes keine strukturelle Gemeinsamkeit mehr zu erwarten? Vermutlich nicht. Die beiden mögen vielleicht hier und da noch dieselben Entwurfsmuster einsetzen -doch darüber hinaus wird es kaum mehr Gemeinsamkeiten geben.
Jenseits der Werkzeuge und der durch sie vertretenen Konzepte herrscht wenig Konsens in der Softwareentwicklung. Compiler schaffen Gemeinsamkeit bei der Sprache mit ihrem fundamentalen Programmierparadigma. IDEs schaffen Gemeinsamkeit beim Aufbau von Benutzeroberflächen und der Quellcodegrundstruktur. Datenbanken schaffen Gemeinsamkeit bei der Datenorganisation.
Wo Werkzeuge oder Konzepte unbekannt oder nicht weit verbreitet sind, herrscht deshalb im Umkehrschluss keine Gemeinsamkeit; weder in der Vorgehensweise noch in Bezug auf die Produktion oder in Architekturfragen. Die Agilitätsbewegung bemüht sich zwar; Team Foundation Server & Co bemühen sich auch; aber es ist unwahrscheinlich, dass die beiden Entwickler in ihrem Gespräch hier schon viele Gemeinsamkeiten entdecken würden. Und noch unwahrscheinlicher ist es in Bezug auf den grundsätzlichen Aufbau ihrer Anwendungen, also ihre Architektur.
Diese Abwesenheit von Gemeinsamkeiten halte ich für überraschend und kontraproduktiv. Nach 50 Jahren Softwareentwicklungspraxis ist die Zahl der Gemeinsamkeiten zwischen zwei Anwendungen immer noch an einer Hand abzählbar. Das gibt es in keiner anderen Branche. Der Ruf nach Standards ist allerorten zu hören, von den Programmiersprachen über die Kommunikation bis zu Office-Dokumentenformaten; was den inneren Aufbau einer Anwendung angeht, verhallt er ungehört.
Das Resultat: geringe Produktivität. Denn wo kein Konsens herrscht, ist immer erst ein Weg zu bahnen. Das kostet Ressourcen.
Kreativer und produktiver mit Regeln
Mehr Konsens und mehr Systematik tun Not. Softwareentwicklung sollte in mehr Aspekten klaren Regeln und typischen Lösungen folgen, die in mindestens 80 Prozent der Fälle zu ausreichenden Implementierungen führen. Die Normalisierungsregeln für relationale Datenbanken sind dafür vielleicht das beste Beispiel: Sie machen klare Vorgaben, sind leicht umzusetzen, führen zu verständlichen Strukturen und sorgen für Wartbarkeit. In den meisten Fällen sind die sich daraus ergebenden Datenbanken auch effektiv genug. Falls nicht, ist es auch kein Verrat, eine Regel auch mal zu brechen. Den grundsätzlichen Konsens beeinträchtigt das nicht. Er hilft, den Kopf für das Wesentliche, die Problemdomäne, freizuhalten.
Ähnliches gilt auch für die Objektorientierung. Sie ist Konsens, was das allgemeine Programmierparadigma angeht. Dass zwei Entwickler für ein Problem unabhängig voneinander eine objektorientierte Sprache wählen, ist sehr wahrscheinlich. So wird es einfach, produktive Teams zusammenzustellen.
Entwurfsmuster haben das Ziel, Gleiches auf einer höheren Abstraktionsstufe zu wiederholen. Sie definieren ein Vokabular für wiederkehrende Probleme mit probaten Lösungen. MVC und Schichten sind vielleicht die bekanntesten Beispiele. Beide sind übersichtlich und leicht verständlich, beide haben ein klares Anwendungsgebiet. Beim Vorgehensmodell könnte Scrum [1] das Zeug dazu haben, ein konsensfähiges Minimalmuster zu werden.
Konventionen und Regeln bedeuten allerdings nicht sklavisches Befolgen. Sie sollen zunächst nur den Blick leiten und Ordnung in das Chaos bringen. Die schnelle 80-Prozent-Lösung ist ihr Zweck. Sie können selbstverständlich gebrochen werden. Denormalisierung ist nicht nur erlaubt, sondern manchmal einfach geboten. Wer allerdings eine Regel bricht, muss sich erklären. Und das ist gut so. Das schafft Bewusstsein und Verantwortungsgefühl für das, was man tut.
Mehr Regeln machen das Leben leichter, weil sie uns Entscheidungen abnehmen. Sie schaffen sogar Spielräume. Fragen Sie einen Künstler: Der wird Ihnen sagen, dass Kreativität von Beschränkung profitiert, ja, sie geradezu braucht.
Regeln sind auch konform mit der Philosophie der Lean Production und der Agilitätsbewegung, Entscheidungen so spät wie möglich zu treffen. Denn wer nach einer Regel handelt, der muss eigentlich noch