Die drei Schichten des Komponentenbaus

Da ich ja letzte Woche meine freche These in die Welt geschrien hab, dass man Architektur und Qualitätsmanagement nicht unbedingt braucht, möchte ich es wieder gut machen und etwas über Architektur schreiben. Ich wurde vor kurzem gefragt, wie man eigentlich richtig modularisiert. Bestimmt gibt es viele Fachbücher über das Thema, aber heute wollen wir mal meine Sicht darauf sehen. Für den Anfang brauchen wir natürlich ein Modul bzw. eine Komponente, die wir bauen wollen. Nehmen wir eine Facebook-Anbindung an WordPress. Keine Sorge, das hat hier nichts mit WordPress oder Facebook zu tun, ich will’s nur anschaulich machen. Ihr könnt eine per Suchen und Ersetzen aus WordPress Symfony machen und aus Facebook Twitter. Sollte trotzdem noch alles gültig sein.

1. Also gut, wir bauen eine Komponente. Die meisten Frameworks auf die wir aufsetzen geben und eine Struktur vor, wo wir was ablegen müssen.  Das machen wir doch einfach und erstellen eine leere Komponente im richtigen Verzeichnis. Auch wenn es der Einstiegspunkt dieses Moduls ist, ist es wohl auch die Stelle mit dem wenigsten Code, denn hier kommen wirklich nur Dinge rein, die tatsächlich eine Abhängigkeit zum verwendeten Framework haben. Vielleicht nutzen wir die Caching-Schicht oder wir wollen die Usernamen abgleichen. Alles was mit Facebook zu tun hat, kommt in eine andere Schicht. Warum? Naja, ich glaube nicht, dass irgendwas was wir in Interaktion mit Facebook machen irgendwas wirklich mit WordPress zu tun hat. Und wir wollen ja jedes x-beliebige Framework anbinden können. Sonst müssten wir ja die Arbeit doppelt machen.
2. Jetzt kommen wir zu der zweiten Schicht. Die eigentliche Facebook-Komponente. Hier findet die eigentliche Kommunikation mit Facebook statt. Dieser Code muss so gebaut sein, dass es keine Abhängigkeiten nach außen zu einem Framework oder anderen „höheren Instanzen“ gibt. Wir wollen den Stück Code ja immer noch verwenden können, wenn WordPress ein Update durchführt oder wir wie oben beschrieben auf Symfony umsteigen wollen. Das ist jetzt schon mal die wichtigste Trennung. Bitte keinen Zugriff auf Facebook direkt im Controller implementieren, das wäre echt schmutzig. Und wir wissen ja, dass im Controller eh keine Logik sein darf.
3. Ich habe ja vorhin von drei Schichten geredet. Natürlich kann man auch aus der Facebook-Komponente Bestandteile rausholen, die man wiederverwenden möchte. Wäre ja gelacht, wenn da nicht auch irgendwas rausfällt, das man in einer anderen Komponente aus einsetzen könnte. Vielleicht fällt ja eine schöne SOAP- oder REST-Anbindung dabei raus (ok wahrscheinlich bietet das Zend Framework das schon), aber sicherlich wird man kleinteilige Funktionalitäten rausholen können. Ich hatte ja glaube ich schon mal geschrieben, dass sich jeder eine solche Basis-Bibliothek aufbauen sollte.

Fassen wir also noch mal kurz zusammen. Wir haben in der ersten Schicht nur Funktionalitäten drinnen, die wirklich projektspezifisch sind und die Abhängigkeiten zum Framework haben. Schicht zwei erledigt die eigentliche Aufgabe und die dritte Schicht unterstützt dies, indem sie Basisfunktionalitäten liefert. So einfach ist das. Jetzt können wir ohne Probleme auch noch nach dem Update oder Austausch eines Frameworks die Komponenten nutzen, ohne viel neu schreiben zu müssen. Eine schöne Separation of Concerns haben wir auch noch. Eigentlich sollte ich noch ein Bild dazu malen, vielleicht reiche ich das noch nach. Kann man nämlich schön visualisieren.