Facade
Eine einfache Schnittstelle vor einem komplexen Teilsystem
Die Idee und ihr Nutzen
Bei einer Versicherung können Schäden über drei Zugänge gemeldet werden: im Kundenportal, über die Maklerschnittstelle als Zugang für Makler und am Telefon über die Anwendung des Kundenservice. Ihre Schäden führt die Versicherung im Schadensystem. Um einen Schaden anzulegen, muss das Schadensystem mehrere Schritte in der richtigen Reihenfolge erledigen: erst den Vertrag prüfen, dann den Schaden speichern und dabei eine Schadennummer vergeben. Ein zusätzlicher Programmteil bietet dafür einen einzigen Aufruf zum Anlegen eines Schadens an, schadenAnlegen, und erledigt die Schritte selbst. Die drei Zugänge müssen die Einzelschritte nicht kennen. Kommt später ein Schritt hinzu, etwa eine Betrugsprüfung vor dem Speichern, ergänzt das Team des Schadensystems den Schritt nur in diesem Programmteil, und die drei Zugänge bleiben unverändert. Dieser Programmteil heißt Facade, auf Deutsch Fassade. Der Name meint: Die drei Zugänge sehen nur den Aufruf schadenAnlegen und nicht die Programmteile, die die Fassade dafür aufruft.
Wie funktioniert es?
Ein Kunde meldet im Kundenportal einen Wasserschaden zu seinem Vertrag 88123. Das Kundenportal ruft bei der Fassade Schadenerfassung nur schadenAnlegen auf und übergibt die Vertragsnummer und die Schadenangaben. Die Fassade Schadenerfassung fragt zuerst die Vertragsprüfung, einen Programmteil des Schadensystems. Die Vertragsprüfung lädt den Vertrag, prüft, ob Vertrag 88123 Leitungswasserschäden deckt, und antwortet „gedeckt“. Dann lässt die Fassade Schadenerfassung den Schaden im Schadenspeicher anlegen, einem weiteren Programmteil des Schadensystems. Der Schadenspeicher vergibt die Schadennummer 4711 und gibt sie an die Fassade Schadenerfassung zurück. Die Fassade Schadenerfassung gibt die Schadennummer an das Kundenportal weiter, das sie dem Kunden anzeigt. Von den Aufrufen der Fassade an Vertragsprüfung und Schadenspeicher weiß das Kundenportal nichts. Meldet eine Maklerin am selben Tag einen Schaden über die Maklerschnittstelle, löst derselbe Aufruf schadenAnlegen genau denselben Ablauf aus. Ein halbes Jahr später führt die Versicherung eine Betrugsprüfung ein, die vor dem Speichern laufen soll. Das Team des Schadensystems ergänzt die Betrugsprüfung in der Fassade Schadenerfassung: Die Fassade ruft die Betrugsprüfung nach der Vertragsprüfung und vor dem Speichern auf. Kundenportal, Maklerschnittstelle und die Anwendung des Kundenservice bleiben unverändert, denn sie rufen weiterhin schadenAnlegen auf und erhalten weiterhin eine Schadennummer oder eine Fehlermeldung.
Das Schadensystem gehört einem eigenen Team. Die Programmteile des Schadensystems können nur gemeinsam einen Schaden anlegen. Drei weitere Teams entwickeln Kundenportal, Maklerschnittstelle und die Anwendung des Kundenservice. Das Team des Schadensystems baut die Fassade Schadenerfassung als zusätzlichen Programmteil. Die Zugänge rufen nur die Fassade auf, und erst die Fassade ruft die übrigen Programmteile des Schadensystems auf. Das Team des Schadensystems legt fest, welche Aufrufe die Fassade anbietet. Es sind wenige, fachlich benannte Aufrufe wie schadenAnlegen mit Vertragsnummer und Schadenangaben. Eine solche vereinbarte Form eines Aufrufs, also sein Name, die übergebenen Angaben und die Art der Antwort, heißt Schnittstelle. Die Fassade Schadenerfassung bietet diese Schnittstelle an, und die drei Zugänge rufen sie auf. Die Reihenfolge „erst Vertragsprüfung, dann Speichern“ ist nur in der Fassade festgelegt.
Ob die drei Zugänge Vertragsprüfung und Schadenspeicher zusätzlich direkt aufrufen dürfen, entscheidet das Team des Schadensystems gesondert. Die Fassade verhindert solche direkten Aufrufe nicht von selbst. Soll das ausgeschlossen sein, muss das Team des Schadensystems diesen Zugriff ausdrücklich sperren. Die Fassade erspart den Zugängen außerdem nur die Einzelaufrufe. Sie macht Vertragsprüfung und Schadenspeicher weder schneller noch zuverlässiger.
Deckt der Vertrag den Schaden nicht, bricht die Fassade Schadenerfassung nach der Vertragsprüfung ab und gibt die Fehlermeldung „Vertrag deckt diesen Schaden nicht ab“ zurück. Alle drei Zugänge erhalten in diesem Fall dieselbe Fehlermeldung.
Fassade: ein Aufruf für die ganze Schadenerfassung
Wann ist es sinnvoll und wann nicht?
Eine Facade lohnt sich
- Mehrere Programme nutzen ein Teilsystem mit vielen Programmteilen auf ähnliche Weise. Programmiert jeder der drei Zugänge die Schritte selbst, gibt es dieselbe Abfolge dreimal, und jeder Zugang muss alle Einzelheiten des Schadensystems kennen.
- Schritte kommen hinzu oder ändern sich. Ohne Fassade müssten für die Betrugsprüfung drei Teams ihren Code ändern. Vergisst eines dieser Teams den neuen Schritt, werden Schäden über seinen Zugang ohne Betrugsprüfung angelegt. Ein Zugang, der die Fassade nutzt, kann dagegen keinen Schritt auslassen.
- Das Teilsystem soll intern umgebaut werden können. Ohne Fassade ruft jeder Zugang die Programmteile selbst auf, und jeder Umbau des Schadensystems zwingt alle drei Teams der Zugänge zu Änderungen. Bleibt die Bedeutung von
schadenAnlegengleich, bleiben die drei Zugänge unverändert. Die Teams der Zugänge können ihre Programme so weiterentwickeln, ohne jede Änderung im Schadensystem nachvollziehen zu müssen. - Ein Altsystem verlangt viele einzelne Aufrufe, und neue Programme sollen es mit einem Aufruf je Aufgabe nutzen können. Ohne Fassade müsste jedes neue Programm alle Einzelaufrufe des Altsystems und ihre Reihenfolge kennen.
- Ein großes Programm soll in Teile gegliedert werden, die einander nur über festgelegte Aufrufe nutzen, und andere Teile sollen nur über die Fassade zugreifen. Ein Beispiel ist der Modular Monolith. Seine Teile bieten ihre Aufgaben den anderen Teilen oft über eine Fassade an. Ohne Fassade greifen andere Teile auf beliebige Programmteile eines Teils zu, und jede interne Änderung dieses Teils kann die anderen Teile betreffen.
Eine Facade ist nicht das Richtige
- Kundenportal, Maklerschnittstelle und die Anwendung des Kundenservice brauchen sehr unterschiedliche Kombinationen der Einzelschritte. Die Fassade müsste dann für fast jeden Zugang eigene Aufrufe anbieten, und das Team des Schadensystems müsste jeden dieser Aufrufe pflegen. Stattdessen ruft jeder Zugang die Programmteile direkt auf, in der Kombination, die er braucht. Das Team jedes Zugangs muss dann selbst wissen, in welcher Reihenfolge die Schritte laufen müssen.
- Es gibt nur einen einzigen Aufrufer, dessen Team die Einzelschritte ohnehin kennen muss. Die Abfolge der Schritte steht dann ohnehin nur einmal im Code, und eine Fassade würde keine doppelte Abfolge ersparen. Dann ruft dieser Aufrufer die Programmteile direkt auf, und der zusätzliche Code der Fassade und der Zwischenschritt bei jedem Aufruf entfallen.
- Ein Aufrufer braucht gezielt einen einzelnen Schritt. Ein Beispiel ist nur die Vertragsprüfung für eine Auskunft am Telefon. Der Aufruf
schadenAnlegenwürde dabei gleich einen Schaden anlegen. Dann ruft die Anwendung des Kundenservice die Vertragsprüfung direkt auf, wenn das Team des Schadensystems diesen Zugriff erlaubt. Die Fassade muss dafür keinen weiteren Aufruf anbieten. - Eine vorhandene Schnittstelle hat nur eine andere Form, als der Aufrufer erwartet, und es gibt keine Abfolge mehrerer Schritte, die eine Fassade bündeln könnte. Dann baut das Team des Aufrufers einen Adapter. Der Aufrufer schickt jeden Aufruf an den Adapter, und der Adapter übersetzt den Aufruf in die Form der vorhandenen Schnittstelle und ruft sie auf.
- Alle Zugänge werden gemeinsam ausgeliefert. Eine Änderung wie die neue Betrugsprüfung erreicht dann alle drei Zugänge mit derselben Auslieferung, auch ohne Fassade. Dann gibt das Team des Schadensystems die Schritte als gemeinsame Programmbibliothek an die drei Zugänge weiter, also als fertigen Code, den jeder Zugang einbindet. Jeder Zugang führt die Schritte dann selbst aus, und der Zwischenschritt über die Fassade bei jedem Aufruf entfällt.
- Die Teilsysteme laufen als getrennte Dienste im Netz, und Programme außerhalb der Versicherung greifen darauf zu. Eine Fassade bündelt nur die Programmteile eines einzigen Teilsystems, so wie die Fassade Schadenerfassung die Programmteile des Schadensystems. Die Programme außerhalb der Versicherung müssten weiter die Adresse jedes einzelnen Dienstes kennen. Dann nimmt ein API Gateway, ein eigenes Programm, alle Aufrufe von außen zuerst an und leitet jeden Aufruf an den zuständigen Dienst weiter. Die Programme außerhalb der Versicherung müssen dann nur die Adresse des API Gateways kennen.
Nachteile und typische Fehler
Die Fassade ist zusätzlicher Code und ein zusätzlicher Zwischenschritt bei jedem Aufruf. Alle drei Zugänge hängen von der Fassade Schadenerfassung ab. Braucht ein Zugang einen neuen Aufruf, muss das Team des Schadensystems die Fassade erweitern, und eine Änderung an der Bedeutung von schadenAnlegen betrifft alle drei Zugänge zugleich.
Typische Fehler und woran man sie erkennt:
- Übergroße Fassade: Das Team des Schadensystems ergänzt für jeden Sonderwunsch eines Zugangs einen eigenen Aufruf, bis die Fassade Dutzende Aufrufe hat und schwer zu überblicken ist. Erkennbar ist das an Aufrufen, die jeweils nur ein einziger Zugang verwendet, und an einer Fassade, die bei fast jeder Änderung angefasst wird.
- Umgehung der Fassade: Das Team des Schadensystems hat den direkten Zugriff auf den Schadenspeicher nicht gesperrt. Die Maklerschnittstelle legt Schäden direkt im Schadenspeicher an und überspringt Vertragsprüfung und Betrugsprüfung. Beim nächsten Umbau des Schadensystems ist dieser Zugang außerdem betroffen. Erkennbar ist das an Schäden ohne Ergebnis der Betrugsprüfung oder zu Verträgen, die den Schaden nicht abdecken.
- Stillschweigend geänderte Bedeutung: Das Team des Schadensystems ändert, was
schadenAnlegentut, ohne die Zugänge zu informieren. Schäden ab einer bestimmten Höhe lässt die Fassade jetzt erst nach einer Freigabe im Schadenspeicher anlegen und antwortet bis dahin „zur Prüfung vorgelegt“ statt mit einer Schadennummer. Das Kundenportal erwartet aber eine Schadennummer oder eine Fehlermeldung und zeigt dem Kunden eine Fehlermeldung, obwohl die Meldung angekommen ist. Erkennbar ist das an Kunden, die denselben Schaden nach einer Fehlermeldung ein zweites Mal melden. - Code für einzelne Zugänge in der Fassade: Das Team des Schadensystems baut auf Wunsch einzelner Teams Code in die Fassade ein, der nur einen Zugang betrifft. Beispiele sind die Aufbereitung von Texten für das Kundenportal und Prüfungen von Eingaben, die nur über die Maklerschnittstelle kommen. Jede solche Änderung muss das Team des Schadensystems umsetzen und mit allen drei Zugängen testen. Erkennbar ist das an Änderungen in der Fassade, die das Team eines Zugangs angefordert hat und die die übrigen Zugänge nicht brauchen.
Weiterführend
Verwandte Ansätze
- Backend for Frontend: bündelt für eine einzelne Oberfläche, etwa eine Smartphone-App, die Aufrufe vieler Dienste und ist damit eine Fassade, die statt Programmteilen ganze Dienste zusammenfasst.
- Anti Corruption Layer: ein Programmteil, der zwischen dem eigenen und einem fremden System übersetzt und oft eine Fassade zu diesem System enthält.
Werkzeuge und Umsetzungen
Die Fassade ist ein Entwurfsmuster, also eine Bauweise, die Entwickler selbst programmieren. Bekannte Beispiele in Open-Source-Projekten:
- SLF4J: Der Name steht für „Simple Logging Facade for Java“. SLF4J ist eine Fassade, über die Java-Programme Protokolleinträge schreiben, ohne die dahinterliegende Protokollbibliothek zu kennen.
- Laravel: Programmrahmen für die Sprache PHP, der viele seiner Dienste über sogenannte Facades anbietet. Laravel verwendet den Begriff allerdings anders als das Entwurfsmuster, nämlich als kurze Schreibweise, mit der Code einen einzelnen Dienst aufruft, etwa
Cache::get('kunde').
Quellen
- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software: Buch von 1994, in dem die Fassade als eines der Strukturmuster zuerst beschrieben wurde.
- Refactoring Guru: Facade: erklärt das Muster mit Bildern, nennt die Gefahr einer übergroßen Fassade und grenzt sie vom Adapter ab.