Einfachheit & Komplexitätsbudget
Einfachheit hält einen Entwurf verständlich und betreibbar. Ein Komplexitätsbudget macht sichtbar, welche zusätzlichen Mechanismen für belegte Anforderungen eingesetzt werden.
- Belegter BedarfMechanismen brauchen einen Nachweis.
- Laufende KostenJeder Mechanismus kostet dauerhaft Verständnis und Betrieb.
- BudgetDas Team kann nur begrenzt Komplexität tragen.
Einordnung
Warum das wichtig ist
Jeder zusätzliche Mechanismus verursacht laufende Kosten in Kommunikation, Konsistenz und Betrieb. Ohne belegten Bedarf wird er zur Last. Einfach ist nicht leicht (Rich Hickey, „Simple Made Easy“): einfach heißt nicht verflochten, leicht heißt vertraut. Woher Komplexität stammt, behandelt der Baustein Komplexität.
Dieser Baustein erklärt die bewusste Wahl zusätzlicher Mechanismen. Für die Herkunft verschiedener Komplexitätsarten siehe Komplexität.
Auf einen Blick · Mechanismen gegen Komplexitätsbudget
Wofür gibt der Shop sein Komplexitätsbudget aus?
Das Shop-Team prüft, ob Bestellung und Rechnung getrennte Services benötigen. Aktuell arbeiten sie in einem modularen Monolithen mit gemeinsamem Release.
So liest du das Bild
- Belegter Bedarf Das Etikett „belegt“ oder „vermutet“ an jedem Mechanismus mit seiner Begründung.
- Laufende Kosten Die Punkte je Mechanismus: vom Cache mit 1 bis zum Event Sourcing mit 4.
- Budget Der Balken gegen die Kapazität 10: Er füllt sich mit jedem zugeschalteten Mechanismus.
4 von 10 PunkteWas das kleine Shop-Team verstehen und betreiben kann
Noch 6 Punkte frei. Alles Ausgegebene ist belegt.
Werte illustrativ
Was kostet der zusätzliche Mechanismus?
| Kriterium | Modularer Monolith heute | Getrennte Services (Variante) |
|---|---|---|
| Belegter Bedarf | gemeinsames Release genügt | erst bei unabhängigen Releases |
| Kommunikation | lokaler Modulvertrag | Netzwerkvertrag und Fehlersemantik |
| Datenkonsistenz | eine lokale Transaktion für B-1042 | verteilte Abstimmung nötig |
| Betrieb | ein Prozess | mehrere Deployments und Beobachtung |
| Wahl für den Shop | ausreichend | Nutzen derzeit nicht belegt |
Nutzen & Grenzen
Hilft, wenn
- Ein kleines Team braucht einen tragfähigen Einstieg mit überschaubarem Betrieb.
- Ein Entwurf ergänzt vorsorglich Plattformen oder Abstraktionen, deren Nutzen noch unklar ist.
Grenzen
- Einfach heißt nicht strukturlos: Zu wenig Struktur ist ebenfalls teuer und endet im „Big Ball of Mud“. Einfachheit braucht Disziplin, etwa durch Modulgrenzen.
- Ein früher einfacher Entwurf kann bei wachsendem Bedarf zur Grenze werden. Beobachte messbare Treiber; die Trade-off-Analyse zeigt, wann eine gezielte Erweiterung lohnt.
In der Praxis
- Aktuelle Aufgabe und Hindernis benennen. Beschreibe den Bedarf, der jetzt gelöst werden muss. Das Ergebnis trennt belegte Anforderungen von vermuteten späteren Erweiterungen.
- Kleinsten tragfähigen Entwurf wählen. Erfülle Qualitätsziele und Constraints mit der überschaubarsten Struktur. Vergleiche verbleibende Zusatzmechanismen anhand ihrer Kosten und Komplexität.
- Wirkung und Änderungsdruck beobachten. Lege fest, welche Messung oder Erfahrung eine Erweiterung begründet. Eine Trade-off-Analyse verbindet neue Last oder Teamzuständigkeit mit einer passenden Struktur.
Ausführliche Erklärung lesen
Ein einfacher Entwurf ist in seinem Kontext leicht zu erklären, zu ändern und zu betreiben. Er lässt notwendige fachliche Regeln sichtbar und fügt technische Mechanismen nur dann hinzu, wenn sie ein belegtes Bedürfnis erfüllen. Komplexität unterscheidet notwendige Regeln von zusätzlichem Aufwand; Trade-off-Analyse prüft Nutzen gegen Kosten.
Einfachheit zeigt sich darin, wie gut reale Aufgaben zu erklären, zu ändern und zu betreiben sind; Datei- und Technologiezahl geben dafür allein keinen Maßstab. Eine zusätzliche Plattform kann den Betrieb erschweren, eine klare Modulgrenze ihn vereinfachen. Beobachte deshalb Änderungs-, Last- und Betriebsanforderungen und passe den Entwurf an, wenn sich der belegte Bedarf verändert.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele Punkte kosten die drei belegten Mechanismen zusammen?
Lösung mit Begründung ansehen
4 von 10 Punkten: Modulgrenzen 1, Queue 2 und Cache 1. Es bleiben 6 Punkte Reserve.
AnwendenAuf eine neue Lage übertragen
Das Rechnungsteam will ab sofort unabhängig von der Bestellung ausliefern. Was ändert sich in der Bewertung?
Lösung mit Begründung ansehen
Damit entsteht der Bedarf „unabhängige Releases“, der laut Zeile Belegter Bedarf getrennte Services begründen kann. Dann sind Netzwerkvertrag, Fehlersemantik und mehrere Deployments einzuplanen.
BewertenEine Alternative abwägen
Das Team will vorsorglich Services trennen, um später flexibler zu sein. Wie wägst du ab?
Lösung mit Begründung ansehen
Vorteil: spätere Trennung wäre vorbereitet. Nachteil: Netzwerkvertrag, verteilte Abstimmung und mehrere Deployments sind sofort zu tragen, der Nutzen ist derzeit nicht belegt. Besser: warten, bis der Bedarf feststeht.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler · YAGNI (öffnet in neuem Tab)Erklärt die Kosten vorsorglich eingebauter Funktionen und Abstraktionen.
- Google SRE · Simplicity (öffnet in neuem Tab)Erklärt betriebliche Kosten von Komplexität und klare Systemgestaltung.
- Martin Fowler · Monolith First (öffnet in neuem Tab)Erklärt den schrittweisen Weg zu stabilen Modul- und Servicegrenzen.
- Rich Hickey · Simple Made Easy (InfoQ) (öffnet in neuem Tab)Unterscheidet einfach (nicht verflochten) von leicht (vertraut).