Design Patterns verkörpern sozusagen das destillierte Wissen der Software-Experten dieser Welt. Tritt bei der Entwicklung einer Software ein technisches Problem auf, kann ein geeignetes Pattern zu dessen Lösung ausgewählt und anwendungsspezifisch umgesetzt werden. Klingt einfach, nicht wahr?
Aufstieg und Fall
Bei diesem Versprechen ist es kein Wunder, dass mit der Veröffentlichung des Buchs „Design Patterns, Elements of Resusable, Object-Oriented Design“ im Jahr 1994 ein regelrechter Hype um Design Patterns begann. Die vier Autoren – mit einem Augenzwinkern, vor allem aber respektvoll als „Gang-of-Four“ bezeichnet – waren Rockstars der Szene; und kamen wie diese, wo immer sie auftraten, aus dem Geben von Autogrammen kaum heraus.
In den darauffolgenden 10 Jahren sprossen Design Patterns wie Pilze aus dem Boden und begründeten einen regelrechten Boom. Bücher wie die „Pattern-Oriented Software Architecture“-Serie der „Party of Five“, „Patterns of Enterprise Application Architecture” von Martin Fowler und “Enterprise Integration Patterns” von Gregor Hohpe und Bobby Woolf standen monatelang auf den Bestsellerlisten von Amazon. „Pattern-Languages of Programming“-Konferenzen wurden in der gesamten Welt aufgesetzt. Design Patterns waren aus keiner Ausbildung für Informatiker und Entwickler wegzudenken. Entwickler diskutierten über ihre Software Systeme in der Sprache der Patterns, die sie bei deren Erstellung angewendet haben.
„Software patterns have significantly changed the way we design, implement, and think about computing systems” – lautet konsequenter Weise der Eröffnungssatz eines Buches über das Konzept der Design Patterns aus dem Jahr 2007.
Doch mit der Zeit wurde es ruhig um Design Patterns. Dies lag sicherlich zum einen daran, dass andere Themen das Interesse der Software-Gemeinde auf sich zogen. Es lag aber auch daran, dass es doch nicht so einfach ist, Design Patterns systematisch, durchgängig und gewinnbringend in der Software-Entwicklung einzusetzen. Patterns waren ein Synonym für „gutes Design“. Man glaubte, es könne gar nichts schiefgehen, wenn Architekturen auf der Basis von Design Patterns erstellte würden.
Was für ein naiver Gedanke. Und natürlich ganz und gar unrealistisch. Ich habe eine ganze Menge von Anwendungen gesehen, die von Design Patterns „durchtränkt“ waren, aber dennoch eine schlechte Architektur aufwiesen. Entsprechend heftig war der Kater der Entwicklergemeinde nach dem Erwachen am Morgen nach der großen Party. Manche Entwickler waren so frustriert, dass sie über das „Scheitern“ der Design Patterns schrieben.
Leben im Untergrund
Das nachlassende Interesse an Design Patterns bedeutete jedoch nicht, dass diese komplett von der Bildfläche verschwanden. Denn: Design Patterns – richtig eingesetzt und angewendet – sind ein wesentlicher Bestandteil wohlstrukturierter Software!
Ohne dass viel darüber geredet wurde, haben Software-Experten Design Patterns einfach angewendet. Konsequent, aber ohne großen Aufhebens. Und eine Vielzahl dieser Experten sind heute die Schlüsselpersonen der Softwareplattformen, die wir alltäglich nutzen.
Allein ein Streifzug durch die Java-Bibliotheken zeigt, dass viele Klassen ganz direkt Patterns implementieren. Fast der gesamte Pattern-Katalog der „Gang-of-Four“ findet sich dort wieder. Gregor Hohpe hat vor kurzem auf seiner Website ein „Rambling“ über „Modern Examples for Enterprise Integration Patterns“ veröffentlicht, wo sich eine aktuelle Technologie an die andere reiht. Data-Analytics-Anwendungen, die der Lambda-Architektur folgen, basieren auf Design Patterns, die bereits vor mehr als 15 Jahren dokumentiert wurden. AWS Lambda, eine „ganz neue“ Technologie für Serverless Computing, macht da ebenfalls keinen Unterschied. Patterns, wohin wir nur schauen – sofern wir uns die Brille putzen und mit klarem Blick auf die Technologien sehen, die uns jeden Tag umgeben. Wär hätte das gedacht.
Renaissance
Unabhängig davon, dass moderne Programmierplattformen in ihren Architekturen sehr stark auf Patterns aufsetzen, bemerke ich auch eine Renaissance von Design Patterns, die sich aus der agilen Entwicklung ergibt. Und verstärkt aus ihrer konsequenten Fortführung, dem DevOps-Ansatz.
Anwendungen agil und in kurzer Zeit zu entwickeln, ist nicht leicht. Die vielen Fehlschläge agiler Projekte zeugen davon. Es zeigt sich immer mehr, dass eine klare architektonische Leitplanke dem Erfolg einer agilen Entwicklung zuträglich ist. Kein Wunder – steht dies ja schon im Agilen Manifesto: „continuous attention to technical excellence and good design enhances agility”. Dort steht zwar auch, dass sich die besten Architekturen emergent aus sich selbst organisierenden Teams entwickeln, aber dies heißt nicht, das Architekturen opportunistisch und aus taktischen Gesichtspunkten entstehen sollten. So, wie es dennoch leider allzu oft praktiziert wird. So lange agile Entwicklung nichts mit dem Betrieb der Software zu tun hatte, fiel dies nicht so sehr auf. Zumindest nach meinem Gefühl.
Mit dem neuen Credo von DevOps – „you build it, you run it“ – sieht die Welt schon anders aus. Auch Microservices haben ein internes Design, und dieses sollte passend sein, damit ein Microservice auch „betriebssicher“ realisiert werden kann. Da sind sie wieder, die Design Patterns. Keine neuen, sondern die altbewährten.
Apropos Microservices. Dieser architektonische Ansatz hat seine ganz eigene Komplexität. Einen einzelnen Microservice zu schreiben, nimmt viele Aufgaben und Randbedingungen von den Schultern agiler Teams. Sie werden unabhängig(er) von anderen agilen Teams. Sie können sich auf ihre Hauptaufgabe konzentrieren, dem Erstellen von Features einer Anwendung. Das ist gut so.
Aber: hunderte von Microservices zu einer Anwendung zusammenzuschalten, die alle systemischen Anforderungen erfüllt, ist kein Kinderspiel. Es gibt nichts umsonst. Die inhärente Komplexität einer Anwendung bleibt immer gleich, unabhängig vom gewählten Architekturansatz. Microservices entlasten agile Teams, aber die Komplexität, um welche die Teams erleichtert werden, wird bei deren Orchestrierung wieder drauf gepackt. Die vielen Beiträge im Netz zu diesem Thema sprechen für sich. Ganz zu schweigen davon, was es heißt, einzelne Microservices im laufenden Betrieb einer Anwendung zu deployen, ohne dass deren Stabilität, Korrektheit und Verfügbarkeit geschmälert wird.
Da ist es kein Wunder, dass es in der letzten Zeit Veröffentlichungen zu Microservice Patterns gibt. Ob in Form von Büchern oder Pattern-Katalogen im Netz. Anscheinend ist ja doch ein breiter Bedarf an Design Patterns vorhanden – wär hätte das gedacht. Da Microservice-Anwendungen in der Regel auf den Plattformen aufbauen, die auf Basis von Patterns gestaltet werden, schließt sich der Kreis.
Noch nie so wertvoll wie heute
Die Wiederentdeckung der Design Patterns finde ich natürlich eine prima Sache! Alles andere wäre auch nicht glaubwürdig, denn ich habe ja selbst mehr als ein Jahrzehnt mit ihnen verbracht.
Die Wiederentdeckung der Design Patterns sollte aber nicht dazu führen, in den Hype ihrer Anfänge zurückzufallen. Damit wäre nichts gewonnen. Wichtiger ist es in meinen Augen, Design Patterns bewusst, systematisch und in einer ausgewogenen Balance aus Methodik und Augenmaß anzuwenden. Und auch mal zu entscheiden, kein Design Pattern zu nutzen. Damit durch den Einsatz von Design Pattern tatsächlich auch tragfähige Software-Entwürfe und Implementierungen entstehen. Und nicht einfach Systeme, die „moderne“ Patterns enthalten.
Erfahren Sie mehr über den Einsatz von Patterns!
In einem neuen Praxistraining mit Frank Buschmann erhalten Sie eine Einführung in wichtige Patterns und lernen anhand einer Fallstudie, wie Sie diese konkret anwenden können. Buchen Sie jetzt!