- Die Kernprobleme der Softwareentwicklung entstehen meist nicht innerhalb des Codes, sondern an den Grenzen (Boundaries), an denen Code auf Code und System auf System trifft
- Grenze = ein Punkt, an dem unterschiedliche Anliegen, Verantwortlichkeiten und Kontexte aufeinandertreffen
- Funktionsaufteilung, Modularisierung, Microservices usw. – fast jede Handlung in der Entwicklung ist eine Handlung, die Grenzen schafft
- Die Ironie: Wir schaffen Grenzen, um Komplexität zu beherrschen, aber die Grenze selbst wird zur neuen Quelle von Komplexität
Grenzen im Code
- Aufrufer-Aufgerufener-Grenze: Unklare Verträge wie
null zurückgeben vs. Exceptions werfen
- Interface-Grenze: Gesetz der Leckenden Abstraktion – verborgene Komplexität bricht irgendwann durch die Grenze hindurch
- Abhängigkeitsgrenze: Externe APIs und Bibliotheken können sich ohne Vorankündigung ändern
- Transformationsgrenze: Wie beim Object-Relational Impedance Mismatch kommt es beim Überschreiten von Grenzen zu Informationsverzerrung und -verlust
- Vertrauensgrenze: Grenze zwischen validierten und nicht validierten Daten → Sicherheitslücken wie das Empfangen unsignierter Webhooks
- Design-Implementierungs-Grenze: Von Anforderungen → Design → Implementierung → Betrieb summiert sich in jeder Phase Informationsverlust
Physische Grenzen
- Reihenfolgegrenze: Zwischen asynchronen Punkten kann sich der Zustand ändern, in verteilten Systemen noch gravierender
- Skalengrenze: Wird ein Schwellenwert überschritten, entsteht keine bloß quantitative, sondern eine qualitative Veränderung
- Umgebungsgrenze: Fälle wie „Auf meinem Rechner funktioniert es doch“
- Infrastrukturgrenze: Bei der Trennung von Services lässt sich Atomarität nicht garantieren
Grenzen zwischen Menschen
- Organisationsgrenze: Conways Gesetz – die Organisationsstruktur bestimmt die Systemstruktur. Bei Team-Umstrukturierungen geraten Code- und Organisationsgrenzen aus dem Takt
- Kommunikationsgrenze: Wie beim Stille-Post-Spiel wird die Absicht bei jeder Weitergabe von Anforderungen verändert, implizites Wissen wird oft gar nicht weitergegeben
- Nutzer-Entwickler-Grenze: Grenzen, die Entwickler aus Sicherheitsgründen schaffen, wirken auf Nutzer oft wie lästige Hürden
Wie man Grenzen beherrscht
- Verborgene Grenzen erkennen: Auf Kopplungen achten, die im Code nicht sichtbar sind, etwa wenn zwei Services dieselbe DB-Tabelle gemeinsam nutzen
- Patterns sind nicht die Antwort: Patterns sind nur „unter bestimmten Bedingungen wirksame Lösungen“ – keine blinde Anwendung
- Drei Fragen an jeder Grenze:
- Was überschreitet diese Grenze?
- Was passiert, wenn diese Grenze bricht?
- Wer verwaltet diese Grenze?
- Auch keine Grenze zu ziehen ist eine Wahl: Einen Monolithen beibehalten, vorschnelle Aufteilung vermeiden usw.
- Grenzen entwickeln sich weiter: Man trennt, führt wieder zusammen und teilt erneut auf → bewusste und regelmäßige Neubewertung ist nötig
Noch keine Kommentare.