Strategisches Frontend-Design

Architektur beginnt nicht erst dort, wo wir entscheiden, welcher Store welchen State hält oder welche Klasse welchen Mapper aufruft.

Einige der wichtigsten Entscheidungen fallen viel früher.

Wo verläuft eine fachliche Grenze? Welche Teile eines Systems sollten gemeinsam wachsen und welche möglichst unabhängig bleiben? Welche Verantwortung gehört zu welchem Team? Wo entsteht Kopplung? Und welche Entscheidung sieht heute pragmatisch aus, wird aber in drei Jahren teuer?

Genau dort beginnt für mich Strategisches Frontend-Design.

Warum „strategisch“?

Der Begriff ist bewusst an das strategische Design aus Domain-Driven Design angelehnt.

Dort geht es zunächst nicht um Entities, Value Objects oder Repositories. Es geht um den größeren Zuschnitt: fachliche Grenzen, Verantwortlichkeiten, Beziehungen zwischen Bereichen und die Frage, welche Teile eines Systems überhaupt gemeinsam gedacht werden sollten.

Im Frontend stellen sich ähnliche Fragen.

Soll ein großes Frontend eine Anwendung bleiben oder gibt es gute Gründe für mehrere unabhängig entwickelte Teile? Wo endet ein fachlicher Bereich? Gehört ein Shared Service wirklich allen oder eigentlich niemandem? Brauchen zwei Teams dieselben Modelle, oder ist genau das bereits eine unerwünschte Kopplung?

Solche Entscheidungen liegen oberhalb einzelner Komponenten oder Stores. Sie bestimmen den Raum, in dem später überhaupt sinnvoll implementiert werden kann.

Strategisches Frontend-Design beschäftigt sich deshalb mit dem Zuschnitt des Systems, bevor wir über den Schnitt im Code sprechen.

Grenzen sind selten nur technisch

Viele Architekturprobleme sehen zunächst technisch aus.

Ein Modul wird zu groß. Zwei Teams ändern ständig dieselben Dateien. Ein gemeinsames Modell bekommt immer mehr Sonderfälle. Ein Deployment wird kompliziert. Ein Shared Package kennt plötzlich die Hälfte der Anwendung.

Die Ursache liegt aber nicht zwangsläufig im Code.

Vielleicht ist eine fachliche Grenze unklar. Vielleicht teilen zwei Teams Verantwortung, die eigentlich getrennt sein sollte. Vielleicht wurde eine organisatorische Struktur in die Software übersetzt, die fachlich gar nicht existiert. Oder ein Integrationsmodell wurde gewählt, das kurzfristig bequem war und langfristig immer mehr Abstimmung verlangt.

Deshalb reicht es bei strategischen Fragen selten, nur auf Klassen und Ordner zu schauen.

Architektur verbindet hier Fachlichkeit, Technik, Organisation und Wirtschaftlichkeit.

Ein Schnitt kann technisch elegant und organisatorisch unbrauchbar sein. Er kann Teams unabhängig machen und dafür Infrastrukturkosten erhöhen. Er kann Deployments beschleunigen und gleichzeitig neue Integrationsprobleme schaffen.

Strategische Architektur besteht deshalb oft weniger darin, die perfekte Lösung zu finden, als die Konsequenzen eines Schnitts früh genug sichtbar zu machen.

Zwei Perspektiven auf dieselbe Frage

Die beiden Serien in diesem Bereich betrachten solche Entscheidungen aus sehr unterschiedlichen Richtungen.

Big Ball of Mud

Ein Big Ball of Mud entsteht selten, weil ein Team eines Morgens beschließt, möglichst viel Kopplung zu erzeugen.

Meist wächst er schrittweise.

Verantwortungen werden geteilt, Grenzen werden durchlässiger, kurzfristige Abkürzungen bleiben bestehen und Wissen verteilt sich immer weiter über das System. Jede einzelne Entscheidung kann nachvollziehbar sein. Zusammen entsteht irgendwann eine Struktur, in der Änderungen immer mehr Koordination benötigen.

Die Serie betrachtet deshalb nicht nur den Code. Sie beschäftigt sich auch mit den organisatorischen und wirtschaftlichen Bedingungen, unter denen solche Systeme entstehen und warum es später so schwer wird, sie wieder aufzuteilen.

Microfrontends

Microfrontends beginnen aus der entgegengesetzten Richtung.

Hier ist die Trennung gewollt.

Teams sollen unabhängiger arbeiten, Teile einer Anwendung getrennt entwickeln und möglicherweise sogar unabhängig ausliefern können.

Damit verschwindet die Frage nach Grenzen aber nicht. Sie wird wichtiger.

Ein Microfrontend-Schnitt kann echte Autonomie ermöglichen. Er kann aber genauso gut vorhandene Kopplung lediglich auf mehrere Anwendungen, Repositories oder Deployments verteilen.

Die interessante Frage lautet deshalb nicht, ob Microfrontends modern oder sinnvoll sind.

Sie lautet: Welche Grenze soll dadurch geschützt werden, und welchen Preis sind wir bereit, dafür zu bezahlen?

Strategie schafft den Raum für Taktik

Strategisches und taktisches Design sind für mich keine konkurrierenden Architekturansätze.

Sie beantworten unterschiedliche Fragen.

Strategisches Frontend-Design beschäftigt sich mit Systemgrenzen, Verantwortlichkeiten und Beziehungen zwischen größeren Teilen einer Frontend-Landschaft.

Taktisches Frontend-Design beginnt eine Ebene darunter. Wenn die Grenze grundsätzlich sinnvoll ist, stellt sich dort die Frage, wie sie sich in konkretem Code ausdrückt.

Strategisches Design fragt:

Wo soll die Grenze verlaufen?

Taktisches Design fragt:

Wie bekommt diese Grenze im Code eine Form?

Beides gehört zusammen. Ein sauber geschnittener Store rettet keine falsche Systemgrenze. Eine gute fachliche Grenze hilft aber auch wenig, wenn innerhalb dieser Grenze wieder jede Verantwortung überall landet.

Kein Architekturtheater

Strategische Architektur klingt schnell größer, als sie sein muss.

Nicht jedes Frontend braucht mehrere Deployments, Plattformteams oder ausgefeilte Integrationsmodelle. Manchmal ist ein gut strukturierter Monolith genau die richtige Entscheidung.

Wichtig ist weniger, möglichst viel Architektur zu produzieren.

Wichtiger ist, bewusst zu entscheiden, welche Teile gemeinsam wachsen sollen, welche unabhängig bleiben müssen und welche Kopplung man sich langfristig leisten möchte.

Darum geht es in diesem Bereich.

Nicht um möglichst große Diagramme, sondern um Entscheidungen, deren Auswirkungen meistens deutlich länger leben als der Code, mit dem sie ursprünglich umgesetzt wurden.