Der populärste Ratschlag zu SOLID ist zugleich der am wenigsten hilfreiche: Wende alle fünf Prinzipien überall und jederzeit an, und deine Architektur bleibt sauber.
Das klingt gut in einem Konferenzvortrag. In Produktionssystemen zerbricht es schnell. In durchsatzstarken Diensten, Datenplattformen und integrationslastigen Unternehmens-Codebasen kann starres SOLID zu Schichten von Abstraktionen führen, die niemand braucht, zu Schnittstellen, die einfache Logik verbergen, und zu Factories, die vor allem weitere Meetings erzeugen.
Die SOLID-Prinzipien sind nach wie vor wichtig. Sie sind sehr wichtig. Doch sie funktionieren am besten als Entscheidungswerkzeuge, nicht als Reinheitstests. Gute Ingenieure nutzen sie, um Code mit klaren Grenzen, vorhersehbaren Änderungspfaden und weniger Nebenwirkungen zu schaffen. Sie wissen auch, wann sie mit dem Abstrahieren aufhören, wann sie Schichten zusammenlegen und wann eine direkte Implementierung die sauberere Option ist.
Inhaltsverzeichnis
- SOLID ist ein Werkzeug, kein Dogma
- Die fünf SOLID-Prinzipien erklärt
- Code- und Architekturbeispiele aus der Praxis
- Die pragmatischen Kompromisse beim Einsatz von SOLID
- Häufige Anti-Muster und SOLID-Verstöße
- Langlebige Systeme mit SOLID bauen
- Häufig gestellte Fragen zu den SOLID-Prinzipien
SOLID ist ein Werkzeug, kein Dogma
Blindes Festhalten an SOLID kann eine Codebasis verschlechtern. Das ist der Teil, den viele Teams spät lernen, meist nachdem jemand drei Schnittstellen, zwei Factories und eine Provider-Schicht eingeführt hat, nur um eine Änderung an einer Klasse zu vermeiden, die ohnehin nur einen einzigen Aufrufer hatte.
Richtig eingesetzt schaffen die SOLID-Prinzipien langlebige Software. Sie treiben Teams zu kleineren Verhaltenseinheiten, klareren Abhängigkeitsgrenzen und Code, der Veränderung aufnehmen kann, ohne Schaden über das System hinweg zu verbreiten. Deshalb sind sie seit Jahrzehnten relevant geblieben.
Es gibt auch ein konkretes Qualitätsargument für ihren Einsatz. Die Einhaltung aller fünf SOLID-Prinzipien korreliert mit einer 30-prozentigen Reduktion von Systemfehlern, laut hier zitierten Daten des Software Engineering Institute. Das bedeutet nicht, dass jede Zeile eine zeremonielle Abstraktion braucht. Es bedeutet, dass disziplinierter Entwurf mit der Zeit tendenziell weniger Fehler erzeugt.
Wozu SOLID eigentlich dient
SOLID ist am nützlichsten, wenn ein System eine oder mehrere dieser Eigenschaften aufweist:
- Häufige Änderungen: Geschäftsregeln, Integrationen und Workflows verschieben sich ständig.
- Mehrere Entwickler: Der Code braucht Grenzen, die Übergaben überstehen.
- Betrieblicher Druck: Fehler müssen isoliert und schnell behoben werden.
- Testbarkeitsanforderungen: Verhalten sollte sich leicht mocken, stubben und verifizieren lassen.
Praxisregel: Wenn ein Prinzip die nächste Änderung sicherer macht und das Laufzeitverhalten nicht undurchsichtiger, behalte es. Wenn es nur Zeremonie hinzufügt, stelle es infrage.
Was dogmatisches SOLID falsch macht
Dogmatisches SOLID verwechselt oft Indirektion mit Qualität. Eine in fünf Dateien aufgeteilte Klasse ist nicht automatisch sauberer. Eine Schnittstelle, die vor dem Bestehen einer zweiten Implementierung erstellt wird, ist nicht automatisch zukunftssicher. Ein perfekt entkoppelter Entwurf, der einem Hot Path Latenz hinzufügt, ist nicht automatisch bessere Ingenieurskunst.
Das Ziel ist eine langlebige Architektur. Das bedeutet Code, den man durchdenken, unter Druck testen und weiterentwickeln kann, ohne ihn jedes Quartal neu zu bauen. SOLID unterstützt dieses Ziel, ist aber nicht das Ziel selbst.
Die fünf SOLID-Prinzipien erklärt
Die kürzeste nützliche Erklärung von SOLID lautet: Jedes Prinzip hilft dir, eine andere Art von Komplexität zu beherrschen. Eines zielt auf überladene Klassen. Ein anderes auf brüchige Erweiterungen. Wieder ein anderes schützt die Korrektheit des Verhaltens. Zusammen formen sie Code, der sich auf engere, vorhersehbarere Weise ändert.
Single-Responsibility-Prinzip
Stelle dir SRP so vor, als würdest du einen passenden Schraubendreher statt eines Schweizer Taschenmessers wählen. Das Messer kann vieles. Meist macht es alles davon schlecht.
Eine Klasse verstößt gegen SRP, wenn sie Geschäftsregeln, Persistenz, Formatierung, Retries und Logging an einem Ort behandelt. Das übliche „Vorher“ sieht aus wie ein OrderService, der Bestellungen validiert, in die Datenbank schreibt, eine E-Mail versendet und eine Audit-Nachricht erstellt. Das „Nachher“ teilt diese Belange in fokussierte Kollaborateure auf, sodass eine Änderung an der E-Mail-Formatierung nicht die Bestellvalidierung gefährdet.
Der praktische Nutzen ist eine leichtere Diagnose. Die Anwendung des Single-Responsibility-Prinzips reduziert die Debugging-Zeit um bis zu 40 %, laut einem hier zitierten IEEE-Software-Bericht von 2025. Das deckt sich mit dem alltäglichen Ingenieursalltag. Wenn eine Einheit eine Aufgabe erfüllt, ist die Fehleroberfläche kleiner.
Eine konkrete Möglichkeit, SRP zu prüfen, ist die NOM-Metrik. Entwickler können die Konformität einer Klasse berechnen, indem sie die Methoden n in einer Klasse zählen und die unterschiedlichen Parametertypen T über diese Methoden hinweg erfassen, wie in diesem SRP-Messungspapier beschrieben. Es ist kein Zauberwert, aber es erzwingt eine nützliche Frage: Wie viele Verantwortlichkeiten verstecken sich in dieser API?
Open-Closed-Prinzip
OCP bedeutet, dass du Verhalten erweitern können solltest, ohne stabilen Code neu zu schreiben. Die alltägliche Analogie ist eine Steckdosenleiste. Du fügst ein weiteres Gerät hinzu, indem du es einsteckst, nicht indem du die Wand öffnest und das Gebäude neu verkabelst.
Das übliche „Vorher“ ist ein Selektor voller Bedingungen:
if provider == Stripeelse if provider == PayPalelse if provider == Adyen
Jeder neue Provider verändert alte Logik. Das schafft Risiko in Code, der bereits funktioniert. Das „Nachher“ führt einen gemeinsamen Vertrag ein, und dann implementiert jeder Provider seine eigene Strategie. Der Selektor löst eine Implementierung auf. Bestehende Abläufe bleiben unangetastet.
OCP ist dort am stärksten, wo bekannt ist, dass Anforderungen wachsen, etwa bei Zahlungsmethoden, Versanddienstleistern, Exportformaten oder Drittanbieter-Integrationen. Es ist verschwenderisch, wenn du Erweiterungspunkte für Verhalten erfindest, das sich wahrscheinlich nie ändern wird.
Liskovsches Substitutionsprinzip
Bei LSP geht es um Verhaltensehrlichkeit. Wenn ein Subtyp für einen Basistyp einspringt, sollte sich das System weiterhin korrekt verhalten.
Der klassische Fehlschlag ist eine Vererbung, die in Diagrammen ordentlich aussieht und zur Laufzeit auseinanderfällt. Eine Unterklasse überschreibt eine Methode mit schwächeren Garantien, wirft Ausnahmen, wo der Basisvertrag es nicht tat, oder ändert unerwartet die Semantik. Der Code kompiliert, aber Aufrufer können der Abstraktion nicht trauen.
Ein einfaches „Vorher“-Beispiel ist ein Basis-StorageWriter, der Schreibunterstützung garantiert, während eine abgeleitete Klasse dann für bestimmte Schreibvorgänge eine NotSupportedException wirft. Das „Nachher“ entfernt die falsche Vererbung und modelliert Fähigkeiten direkt. Klassen implementieren nur die Verträge, die sie einhalten können.
Wenn eine Unterklasse Vorbehalte, Sonderfallprüfungen oder defensive Kommentare braucht, um nutzbar zu sein, lügt die Hierarchie wahrscheinlich.
Interface-Segregation-Prinzip
ISP besagt, dass Clients nicht von Methoden abhängen sollten, die sie nicht nutzen. Die Analogie ist ein Bedienpult. Wenn ein Bediener nur Start und Stopp braucht, ist es schlechtes Design, ihm zwölf unzusammenhängende Schalter in die Hand zu drücken.
Das „Vorher“ ist eine breite Schnittstelle wie IReportManager mit Methoden für Erzeugung, Export, Archivierung, Berechtigungen und Benachrichtigungen. Konsumenten hängen vom Ganzen ab, selbst wenn sie nur PDFs erzeugen. Das „Nachher“ teilt das in kleinere Schnittstellen auf, etwa IReportGenerator, IExporter oder INotifier.
ISP zahlt sich an zwei Stellen aus. Erstens werden Mocks einfacher, weil Tests nur das Verhalten implementieren, das sie brauchen. Zweitens werden API-Verträge leichter verständlich, weil jede Abhängigkeit einen engeren Zweck bewirbt.
Dependency-Inversion-Prinzip
DIP ist das Prinzip, das Teams bei Skalierung oft zuerst spüren. High-Level-Module sollten nicht direkt von Low-Level-Details abhängen. Beide sollten von Abstraktionen abhängen.
Das „Vorher“ sieht aus wie ein Anwendungsdienst, der einen konkreten Redis-Client, einen konkreten E-Mail-Versender und ein konkretes SQL-Repository instanziiert. Dieser Dienst besitzt nun Geschäftslogik und Infrastrukturentscheidungen zugleich. Das „Nachher“ injiziert Abstraktionen wie ICache, INotificationSender und IOrderRepository, sodass sich der Dienst auf Orchestrierung und Regeln konzentriert.
DIP ist kein Befehl, für jede Klasse Schnittstellen zu erstellen. Es ist eine Methode, Volatilität zu isolieren. Wenn eine Abhängigkeit sich wahrscheinlich ändert, je nach Umgebung variiert oder in Tests gemockt werden muss, hilft Abstraktion. Wenn es sich um ein stabiles Hilfsmittel ohne nennenswerte Variation handelt, ist die direkte Nutzung oft in Ordnung.
Code- und Architekturbeispiele aus der Praxis
Die nützlichsten SOLID-Beispiele sind keine Spielzeug-Bird-Klassen. Sie tauchen in unübersichtlichen Geschäftssystemen auf, besonders rund um Integrationen, Dienstgrenzen und Datenbewegung.
Refactoring der Integrationsauswahl-Logik
Ein verbreitetes Unternehmensmuster beginnt mit einem konfigurationsgesteuerten Bedingungsblock. Eine Klasse liest Mandanteneinstellungen, wählt eine Integration, mappt Payloads, sendet Anfragen und behandelt Retries. Es funktioniert, bis die vierte oder fünfte Integration hinzukommt.
Solcher Code wächst meist so:
| Phase | Wie der Code aussieht | Was schiefgeht |
|---|---|---|
| Früh | Ein Dienst mit if/else-Integrationszweigen | Schnell ausgeliefert, schwer zu erweitern |
| Wachstum | Mehr Zweige, providerspezifisches Mapping innerhalb des Dienstes | Regressionen beim Hinzufügen eines neuen Pfads |
| Refactoring | Provider-Schnittstelle plus separate Implementierungen | Sauberere Erweiterung und isoliertes Testen |
Ein aktuelles Projekt folgte diesem Muster. Es gab viele Integrationen, und das System musste anhand der Konfiguration wählen, welche es verwendet. Entkoppelte Klassen machten den Unterschied. Sobald die Auswahllogik von Abstraktionen statt von konkreten Implementierungen abhing, konnte das Team Provider hinzufügen oder austauschen, ohne die zentrale Orchestrierung neu zu schreiben.
Hier arbeiten OCP und DIP zusammen. OCP hält den Auswahlpfad stabil. DIP verhindert, dass die Orchestrierungsschicht jedes Detail jeder Integration kennt.
SOLID oberhalb der Klassenebene einsetzen
SOLID spielt auch außerhalb einzelner Klassen eine Rolle.
In Microservices hilft SRP, Dienstgrenzen zu definieren. Wenn ein Dienst Abrechnung, Reporting und Identität abwickelt, weil diese Funktionen zufällig gemeinsam gestartet wurden, verwischen sich seine Deployment- und Fehleroberfläche. Verantwortlichkeiten nach Domäne aufzuteilen schafft eine bessere Änderungskontrolle.
In APIs führt ISP zu engeren Verträgen. Ein zum Konsumenten hin gerichteter Endpunkt sollte keine Allzweck-Payload offenlegen, nur weil das Backend-Team ein einziges „flexibles“ Schema wollte. Fokussierte Verträge halten Konsumenten unabhängig und reduzieren zufällige Kopplung.
In Datenplattformen verbessert DIP das Pipeline-Design. Extraktoren, Transformatoren und Loader können von stabilen internen Verträgen statt von herstellerspezifischen Details abhängen. Das ist besonders nützlich, wenn sich ein Warehouse, ein Message Broker oder ein Dateiziel im Lauf der Zeit ändert.
Eine öffentliche Fallstudie zeigte, wie disziplinierter Entwurf eine strauchelnde Codebasis bereinigen kann. Die Anwendung der SOLID-Prinzipien in einem Projekt, das unter Duplizierung litt, senkte die Code-Duplizierung um über 54 %, wie in dieser Fallstudie zur Duplizierungskrise beschrieben. Die zugrunde liegende Lehre ist nicht „abstrahiere alles“. Es ist, dass wiederholte Logik in der Regel auf fehlende Grenzen hinweist.
Für Teams, die sich durch solche Systemfragen arbeiten, profitiert die Arbeit am Entwurf von Unternehmenssoftware meist am meisten, wenn SOLID sowohl auf Code- als auch auf Architekturebene angewendet wird, nicht nur bei Klassen-Refactorings.
Die pragmatischen Kompromisse beim Einsatz von SOLID
Die ehrliche Antwort auf „Sollten wir SOLID durchsetzen?“ lautet „Ja, aber nicht mechanisch.“
Manche Teams sehen sofortige Gewinne, weil ihre Codebasis chaotisch ist. Andere bremsen sich selbst aus, indem sie zu früh abstrahieren. Der Unterschied ergibt sich daraus, wo die Prinzipien angewendet werden und ob die Abstraktionskosten durch die erwartete Veränderung gerechtfertigt sind.
Wo sich SOLID auszahlt
Wenn ein Team SOLID gut durchsetzt, kann die Feature-Arbeit anfangs länger dauern. Das ist normal. Du verbringst mehr Zeit damit, Grenzen zu benennen, Verantwortlichkeiten aufzuteilen und Verträge zu definieren. Die Belohnung kommt später, wenn Änderungen keine umfassenden Refactorings auslösen.
In der Praxis bemerken Teams oft Kompromisse wie diese:
- Langsamere anfängliche Feature-Auslieferung: Sauberere Abstraktionen brauchen Entwurfszeit.
- Weniger nachgelagerte Bugs: Isolierte Verantwortlichkeiten verkleinern den Wirkungsradius.
- Weniger schmerzhaftes Refactoring: Erweiterungspunkte existieren bereits dort, wo Variation real ist.
- Bessere Review-Qualität: Verantwortlichkeiten und Abhängigkeiten lassen sich leichter prüfen.
Auch hier spielt die Teststrategie eine Rolle. Gute Abstraktion ohne gute Verifikation hinterlässt weiterhin Lücken. Teams, die modularen Entwurf mit QA-Automatisierungspraktiken kombinieren, ziehen meist mehr Nutzen aus SOLID, weil die Verträge fortlaufend beansprucht werden.
Ingenieururteil: Wenn eine neue Abstraktion ein Feature langsamer zu bauen macht, aber wiederholte zukünftige Änderungen an einem bekannten Hotspot beseitigt, ist es ein guter Kompromiss.
Wo Abstraktion zu schmerzen beginnt
Die Kehrseite ist real. In Hochleistungssystemen ist Über-Abstraktion nicht nur lästig. Sie kann betrieblich teuer sein. Über-Abstraktion zwecks SOLID-Konformität erhöht den Speicher-Overhead um 12 bis 18 % und die Antwortlatenz um 8 bis 14 % in C#/.NET-Microservices, die mehr als 10K Anfragen pro Sekunde verarbeiten, laut dieser Diskussion über SOLID-Kompromisse.
Das deckt sich mit dem, was erfahrene Ingenieure regelmäßig in .NET- und Java-Systemen sehen. Der Witz von der „abstractfactorybuilderprovider“ existiert nicht ohne Grund. Teams verwenden manchmal mehr Mühe darauf, über die perfekte Menge an Abstraktionen zu debattieren, als das Verhalten auszuliefern, das die Nutzer brauchen.
Einige Warnzeichen zeigen, dass ein Entwurf die Grenze überschritten hat:
- Abstraktion vor Beleg: Schnittstellen existieren ohne eine zweite Implementierung oder einen realistischen Erweiterungspfad.
- Indirektion im Hot Path: anfragekritische Abläufe hüpfen durch Schichten, die keinen geschäftlichen Wert hinzufügen.
- Namensinflation: Klassen beschreiben eher Muster als Verhalten.
- Review-Lähmung: Ingenieure streiten über die Form der Abstraktion statt über Korrektheit, Fehlerbehandlung oder Laufzeitkosten.
Manchmal ist die sauberste Lösung Subtraktion. Entferne tote Schichten. Lege ungenutzte Schnittstellen zusammen. In manchen Fällen verschiebe einen Knoten unzusammenhängender Logik in einen eigenen Dienst, damit das Hauptsystem eine einfachere Form zurückgewinnt.
Häufige Anti-Muster und SOLID-Verstöße
Die meisten SOLID-Verstöße sind leicht zu erkennen, sobald man weiß, wie sie aussehen. Das Problem ist, dass Teams sie oft als normalen Code statt als Design-Schuld behandeln.
Wie schlechtes SOLID im Review aussieht
Beginne mit SRP. Das Anti-Muster ist die God Class. Sie validiert Eingaben, ruft APIs auf, transformiert Modelle, persistiert Daten und schreibt Logs. Man erkennt sie meist am Scrollen. Wenn die Datei mehrere Belange behandelt, wird irgendwann jemand einen Teil ändern und einen anderen zerbrechen.
Bei OCP ist das verräterische Zeichen die endlose Verzweigungskette. Jedes neue Feature fügt eine weitere Bedingung für einen Typ, Provider, Modus oder eine Region hinzu. Das System wird nur erweiterbar, indem man riskante, zentrale Logik verändert.
LSP-Verstöße sind subtiler. Achte auf Unterklassen, die eine NotImplementedException werfen, null zurückgeben, wo der Elternvertrag einen Wert verspricht, oder von Aufrufern verlangen, Sonderregeln zu kennen. Wenn ein Kind das Elternteil nicht sicher ersetzen kann, ist das Vererbungsmodell falsch.
Eine kurze Review-Checkliste hilft:
- Für SRP: frage, ob die Klasse mehr als einen Grund zur Änderung hat.
- Für OCP: suche nach Bedingungen, die mit jeder unterstützten Variante wachsen.
- Für LSP: prüfe, ob abgeleitete Typen Garantien abschwächen oder erwartetes Verhalten verändern.
- Für ISP: finde breite Schnittstellen, die Implementierungen zwingen, irrelevante Member zu stubben.
- Für DIP: markiere High-Level-Dienste, die direkt Infrastrukturabhängigkeiten erzeugen.
KI-generierter Code braucht Prüfung
KI-Werkzeuge haben ein Anti-Muster häufiger gemacht: plausiblen Schrott-Code. Er kompiliert, folgt vertrauten Mustern und hinterlässt dennoch ein Durcheinander aus Verantwortlichkeiten und zufälliger Kopplung.
Das macht die menschliche Prüfung wichtiger, nicht unwichtiger. Eine nützliche Teamregel ist einfach: Sieh dir deinen Code an, nachdem dein Agent ihn erstellt hat. Akzeptiere nicht einfach fast alles. Denke an die Zukunft des Projekts.
Behandle KI-Output wie einen schnellen Entwurf eines Junior-Entwicklers. Prüfe Verantwortlichkeiten, Verträge und Fehlermodi, bevor er in die Produktion gelangt.
Die SOLID-Prinzipien sind hier nützlich, weil sie Prüfern ein gemeinsames Vokabular geben. Statt zu sagen „das fühlt sich chaotisch an“, kannst du sagen „dieser Dienst verstößt gegen SRP und instanziiert direkt Infrastruktur, verfehlt also auch DIP“.
Langlebige Systeme mit SOLID bauen
Langlebige Systeme entstehen nicht allein aus Regeln. Sie entstehen aus wiederholbarem Entwurfsurteil. Die SOLID-Prinzipien helfen, weil sie nützliche Fragen erzwingen: Was ändert sich gemeinsam, was sollte stabil bleiben, welchem Vertrag können Aufrufer trauen und welche Abhängigkeiten verdienen Isolierung?
Das ist umso wichtiger in Produktionssystemen, in denen die Zuverlässigkeit von Sichtbarkeit und betrieblicher Klarheit abhängt. Ein sauberes Klassendiagramm rettet keinen Dienst, der unmöglich zu beobachten oder zu debuggen ist. Der Entwurf muss unter Last, Fehlern und gewöhnlicher Wartung standhalten. Deshalb sollte Architekturarbeit neben Laufzeit-Feedback wie Tracing, Metriken und Logs stehen. Für diese Seite der Gleichung halten starke Observability-Praktiken Abstraktionen ehrlich.
Wenn Teams einen leichtgewichtigen Weg brauchen, festzuhalten, warum sie sich für eine bestimmte Grenze, Abhängigkeit oder Dienstaufteilung entschieden haben, ist dieser Leitfaden zu Architecture Decision Records von SpecStory, Inc. eine praktische Referenz. Er passt gut zu SOLID, weil beide darauf abzielen, zufällige Komplexität mit der Zeit zu reduzieren.
Der beste Einsatz von SOLID ist stetig und unspektakulär. Wende es dort an, wo es Änderungen eingrenzt, die Korrektheit verbessert und den Betrieb ruhiger macht. Beuge es, wenn Leistung, Einfachheit oder die Form des Systems einen anderen Schritt verlangen.
Häufig gestellte Fragen zu den SOLID-Prinzipien
Kann SOLID bei integrationslastigen Projekten helfen
Ja. Oft hilft es dort am meisten.
Ein aktuelles integrationslastiges Projekt hatte viele Provider-Optionen, die per Konfiguration ausgewählt wurden. Entkoppelte Klassen machten das handhabbar. Sobald jede Integration hinter einem klaren Vertrag lag, konnte das Team Implementierungen hinzufügen oder anpassen, ohne den zentralen Entscheidungsablauf neu zu schreiben. Das verringerte den Refactoring-Druck und beschränkte Bugs auf den Provider, der gerade geändert wurde.
Mit welchem Prinzip tun sich Teams am schwersten
In der Praxis ist der schwierigste Teil nicht das Auswendiglernen von SRP oder DIP. Es ist, Schrott-Code zu widerstehen.
Das ist mit KI-gestützter Entwicklung noch relevanter. Teams müssen generierten Code mit Absicht prüfen. Der Maßstab sollte nicht „es funktioniert“ sein. Der Maßstab sollte sein: „es funktioniert, und die Struktur bestraft nicht die nächsten sechs Monate an Änderungen“.
Wann ist es akzeptabel, ein Prinzip zu brechen
Es ist akzeptabel, wenn das Befolgen des Prinzips das System schlechter machen würde.
Das passiert meist in leistungssensiblen Pfaden oder in Code, der über seinen tatsächlichen Bedarf hinaus abstrahiert wurde. Manchmal ist die beste Lösung, eine Schicht zu entfernen, Abstraktionen zusammenzulegen oder einen Komplexitätsknoten in einen separaten Dienst auszulagern. Entscheidend ist, diesen Kompromiss bewusst einzugehen, mit Blick auf das Laufzeitverhalten und die künftige Wartung.
Woher stammt SOLID
Die SOLID-Prinzipien wurden 1995 von Robert C. Martin formell als einheitliches Akronym eingeführt und vereinten fünf objektorientierte Entwurfsprinzipien, die sich im vorangegangenen Jahrzehnt entwickelt hatten, darunter das Open/Closed-Prinzip von 1988 und das Liskovsche Substitutionsprinzip von 1987, wie in dieser Geschichte der SOLID-Prinzipien dargelegt.
Sie haben Bestand, weil sich die zugrunde liegenden Probleme nicht geändert haben. Software wird immer noch schwerer zu warten, wenn Verantwortlichkeiten verschwimmen, Verträge lügen und Abhängigkeiten an den falschen Stellen erstarren.
Wenn Ihr Team Wartbarkeit, Latenz und reale Produktionsbeschränkungen ausbalanciert, baut Ryware maßgeschneiderte Software, Datenplattformen und Cloud-Systeme mit jener pragmatischen Architekturdisziplin, die Systeme schnell, betreibbar und leichter änderbar hält.