Das Buch „Evolutionäre Architektur. Unterstützung für ständigen Wandel "

Es ist Zeit, einen neuen Blick auf die Postulate zu werfen, die über die Jahre unverändert geblieben sind. Eine sich dynamisch verändernde Welt diktiert ihre eigenen Regeln, auch in der Computerarchitektur. Die Veränderungen, die stattfinden, erfordern neue Ansätze, die starre Systeme dazu zwingen, flexibel zu werden und sich an neue Bedingungen anzupassen. Ist eine langfristige Planung möglich, wenn sich alles ständig ändert? Wie kann verhindert werden, dass sich die architektonische Lösung im Laufe der Zeit allmählich verschlechtert? Hier finden Sie Antworten und Empfehlungen, die die wichtigsten Merkmale des Projekts im Kontext kontinuierlicher Änderungen schützen. „Dieses Buch markiert einen wichtigen Meilenstein im aktuellen Verständnis des Problems. Wenn sich die Menschen der Rolle von Software im 21. Jahrhundert bewusst werden, werden Informationen darüber, wie sie auf Veränderungen reagieren und gleichzeitig das Erreichte beibehalten können, zu einer wesentlichen Fähigkeit in der Softwareentwicklung. “ - Martin Fowler

Evolutionsarchitektur: Fallen und Antimuster

Wir haben viel Zeit damit verbracht, die richtigen Konnektivitätsebenen in der Architektur zu diskutieren. Wir leben jedoch auch in der realen Welt und beobachten viele Zusammenhänge, die die Entwicklungsfähigkeit des Projekts beeinträchtigen.

Es wurden zwei schlechte Entwurfspraktiken identifiziert, die in Softwareprojekten offensichtlich sind: Fallen und Antimuster. Viele Entwickler verwenden das Wort Antipattern als Slang-Begriff „schlecht“, aber seine wahre Bedeutung muss geklärt werden. Antipattern-Software besteht aus zwei Teilen. Erster Teil: Antipattern ist eine Praxis, die zunächst als gute Idee erscheint, sich aber in einen Fehler verwandelt. Zweiter Teil: Für die meisten Antimuster gibt es viele, viel bessere Alternativen. Architekturentwickler bemerken viele Antimuster nur im Nachhinein, daher ist es schwierig, sie zu vermeiden. Die Falle sieht auf den ersten Blick wie eine gute Idee aus, manifestiert sich aber sofort als schlechter Weg. In diesem Kapitel betrachten wir gemeinsam Fallen und Antimuster.

Technische Architektur

Dieser Abschnitt konzentriert sich auf die in der Industrie übliche Praxis, die sich besonders nachteilig auf die Fähigkeit des Teams auswirkt, Architektur weiterzuentwickeln.

Antipattern: Vendor King

Einige große Unternehmen erwerben ERP-Software (Enterprise Resource Planning), um allgemeine Geschäftsaufgaben wie Buchhaltung, Bestandsverwaltung und andere Routinevorgänge zu lösen. Dies funktioniert, wenn Unternehmen bereit sind, ihre Geschäftsprozesse und andere Lösungen zu biegen, um dieses Tool anzupassen, und kann strategisch eingesetzt werden, wenn Architekturentwickler die Einschränkungen und Vorteile verstehen.

Viele Organisationen werden jedoch in Bezug auf Software dieser Kategorie zu ehrgeizig, was zu dem Gegenmuster des Anbieterkönigs führt, dessen Architektur vollständig auf den Produkten des Lieferanten basiert, was die Organisation pathologisch an dieses Tool bindet. Unternehmen, die Lieferanten-Software kaufen, planen, das Paket mit ihren Plug-Ins zu erweitern, um die Grundfunktionalität zu erweitern und es an den Themenbereich des Unternehmens anzupassen. Lange Zeit kann das ERP-Tool jedoch nicht ausreichend konfiguriert werden, um die erforderlichen Anforderungen vollständig zu implementieren, und Entwickler sind aufgrund der Einschränkungen des Tools und weil sie es zum Zentrum des Architekturuniversums gemacht haben, hilflos. Mit anderen Worten, die Architekturentwickler machten den Lieferanten zum König ihrer Architektur und diktierten zukünftige Entscheidungen.

Um Antimuster zu vermeiden, sollte man die Software einfach als einen weiteren Integrationspunkt betrachten, selbst wenn sie anfänglich ein breites Spektrum von Verantwortlichkeiten hatte. Unter der Annahme der Integration im Anfangsstadium ist es einfacher, nutzlose Eigenschaften durch andere Integrationspunkte zu ändern und den König vom Thron zu stürzen.

Durch die Platzierung eines externen Tools oder einer externen Plattform im Zentrum der Architektur haben Entwickler ihre Fähigkeit, sich in zwei Hauptrichtungen zu entwickeln, erheblich eingeschränkt, und zwar technisch und aus Sicht des Geschäftsprozesses. Entwickler sind technisch begrenzt durch die Wahl des Anbieters in Bezug auf Speichersysteme, unterstützte Infrastruktur und viele andere Einschränkungen. Aus Sicht des Themenbereichs leidet ein großes Kapselungswerkzeug letztendlich unter dem Antimuster „Falle auf den letzten 10%“. Aus Sicht der Geschäftsprozesse kann dieses Tool keinen optimalen Workflow unterstützen. Dies ist eine Nebenwirkung oder Falle in den letzten 10%. Die meisten Unternehmen werden geschlossen, indem sie sich an die Plattform wenden, Prozesse ersetzen und nicht versuchen, das Tool anzupassen. Je mehr Unternehmen dies tun, desto weniger Unterscheidungsmerkmale bestehen zwischen den Unternehmen, was groß ist, da der Unterschied kein Vorteil ist.

Das Prinzip, dass wir aufhören zu arbeiten und es Erfolg nennen, ist eines der Prinzipien , die Entwickler normalerweise berücksichtigen, wenn sie mit ERP-Paketen in der realen Welt arbeiten. Da sie erhebliche Zeit- und Geldinvestitionen erfordern, zögern Unternehmen, ihnen zuzustimmen, wenn sie nicht arbeiten. Keine technische Abteilung möchte den Verlust von Millionen von Dollar akzeptieren, und der Anbieter des Tools möchte keine schlechte mehrschichtige Implementierung akzeptieren. Daher ist jede der Parteien damit einverstanden, die Arbeit zu stoppen und sie als Erfolg mit den meisten unerfüllten versprochenen Funktionen zu bezeichnen.

Verknüpfen Sie Ihre Architektur nicht mit dem Lieferantenkönig.

Anstatt dem Gegenmuster des Lieferantenkönigs zum Opfer zu fallen, sollten Sie Lieferantenprodukte als einen weiteren Integrationspunkt betrachten. Entwicklungen können Änderungen im Werkzeug des Lieferanten von den Auswirkungen seiner Architektur isolieren, indem sie Schichten der Widerstandsfähigkeit gegen Zerstörung zwischen Integrationspunkten aufbauen.

Falle: löchrige Abstraktion

Alle nicht trivialen Abstraktionen sind zum Teil voller Löcher.
- Joel Spolsky

Moderne Software basiert auf einem Turm von Abstraktionen: Betriebssystemen, Plattformen, Abhängigkeiten usw. Als Entwickler erstellen wir Abstraktionen so, dass wir nicht in der Lage sind, auf den unteren Ebenen ständig zu denken. Wenn die Entwickler die von den Festplatten kommenden Binärzahlen in den Text für das Programm übersetzen müssten, könnten sie niemals etwas tun! Einer der Triumphe moderner Software ist, wie gut wir effektive Abstraktionen erstellen können.

Aber Abstraktionen sind teuer, weil es keine perfekten Abstraktionen gibt, und wenn sie es wären, wären sie keine Abstraktionen, sondern etwas Reales. Laut Joel Spolsky haben alle nicht trivialen Abstraktionen ein Loch (Leck). Dies ist ein Problem für Entwickler, da wir glauben, dass Abstraktionen immer korrekt sind, aber oft wunderbar zusammenbrechen.

Die zunehmende Komplexität von Technologie-Stacks hat die Abstraktion in letzter Zeit zu einem verheerenden Problem gemacht. In Abb. 7.1 präsentiert einen typischen technologischen Stack aus dem Jahr 2005.

In diesem Stapel ändert sich der Anbietername auf den Blöcken abhängig von den lokalen Bedingungen. Mit der Zeit wird unser Technologie-Stack mit zunehmender Spezialisierung der Software komplexer, wie in Abbildung 2 dargestellt. 7.2.


Wie in Abb. 7.2 hat sich jeder Teil des Software-Ökosystems erweitert und ist komplexer geworden. Da die Probleme, mit denen Entwickler konfrontiert sind, immer komplexer werden, werden auch ihre Lösungen immer komplexer.

Die anfängliche löchrige Abstraktion , bei der destruktive Abstraktion auf niedriger Ebene zu unerwartetem Chaos führt, ist einer der Nebenwirkungen der Erhöhung der Komplexität des technologischen Stapels. Was ist, wenn eine der Abstraktionen auf der untersten Ebene fehlschlägt, beispielsweise ein unerwarteter Nebeneffekt eines scheinbar harmlosen Datenbankaufrufs? Da es so viele Ebenen gibt, wird dieser Fehler an die Spitze dieses Stapels verschoben, was möglicherweise zu „Metastasen“ in seinem Pfad führt und sich in einer tief eingebetteten Fehlermeldung in der Benutzeroberfläche manifestiert. Debugging und retrospektive Analyse werden umso schwieriger, je komplexer der technologische Stack ist.

Versuchen Sie, mindestens eine Abstraktionsebene unterhalb der Ebene, auf der Sie normalerweise arbeiten, vollständig zu verstehen.
- Sages Software

Obwohl das Verstehen der folgenden Ebene ein guter Rat ist, wird es immer schwieriger, dem zu folgen, da sich die Software spezialisiert und komplexer wird.

Die Erhöhung der Komplexität des technologischen Stapels ist ein Beispiel für ein dynamisches Gleichgewichtsproblem. Das Ökosystem verändert sich nicht nur, sondern seine Bestandteile werden im Laufe der Zeit komplexer und verwirrender. Der vorgeschlagene Mechanismus zum Schutz sich entwickelnder Änderungen, nämlich die Verwendung von Fitnessfunktionen, kann die fragilen Punkte von Architekturverbindungen schützen. Architekten definieren Invarianten an wichtigen Integrationspunkten, z. B. Eignungsfunktionen, die als Teil der Bereitstellungspipeline fungieren, um sicherzustellen, dass die Abstraktion nicht auf unerwünschte Weise zu fließen beginnt.

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers

Für habrozhitelami 20% Rabatt auf Gutschein - Evolutionäre Architektur