SoftwareentwicklungDomain-Driven DesignArchitektur

Der Technologie-Tunnelblick: Warum wir lieber über Frameworks reden

Die Softwareentwicklungsbranche hat ihre Aufmerksamkeit von der Lösung fachlicher Probleme zu technischen Debatten verschoben.

Ein überfüllter Holzschreibtisch bei Nacht im kalten Licht einer LED-Lampe. Im Fokus steht ein Laptop mit buntem Quellcode. Daneben liegen die Fachbücher Clean Code, Designing Data-Intensive Applications und Domain-Driven Design sowie ein Notizblock mit der Aufschrift Kundenworkflow Versicherung. Im unscharfen Hintergrund ist ein Whiteboard mit einem Microservices-Diagramm zu erkennen.

Autor: Tobias Müller, ispringen.dev

Der Technologie-Tunnelblick: Warum wir lieber über Frameworks reden als über Probleme

Ich beobachte seit Jahren, wie Diskussionen in Entwicklungsteams ablaufen. Es geht um Frameworks, Architekturstile, die neueste Technologie. Ob Microservices oder Modulith, welches Tool, welche Code-Coverage. Das fachliche Problem, das die Software lösen soll, kommt selten vor. Das ist kein Zufall.

“70 Prozent mehr Stellenausschreibungen für technische Rollen als für Domänenexperten zeigen strukturelle Anreize der Branche.”

Die Branche hat sich an technische Debatten gewöhnt. Sie sind greifbar, messbar, kontrollierbar. Benchmarks, Dokumentationen und Tutorials sind alle teil der Welt, die Entwickler kennen. Fachliche Probleme sind anders. Sie sind vage, widersprüchlich, erfordern Gespräche mit Menschen, die anders denken. Eine Fachexpertin interessiert sich nicht für Kubernetes. Sie will wissen, ob das System ihre Arbeit erleichtert.

Das strukturelle Problem zeigt sich in Stellenausschreibungen. 70 Prozent mehr für technische Rollen als für Domänenexperten. Wer sich mit der neuesten Technologie auskennt, gilt als kompetent. Wer die Fachdomäne einer Versicherung versteht, wird selten auf Konferenzen eingeladen. Das prägt, worauf Teams ihre Energie richten. Es entstehen Systeme, die technisch modern, aber fachlich ahnungslos sind.

Ich denke, jeder Entwickler hat solche Diskussionen geführt. Die Frage ist, warum wir uns nie gefragt haben, warum.

Architektur als Glaubensfrage: Wenn Prinzipien den Blick auf die Domäne versperren

Die Debatte um Microservices versus Monolith ist ein Paradebeispiel. In den 2010er-Jahren galt Microservices fast als Naturgesetz. Wer einen Monolithen baute, musste sich rechtfertigen. Die fachliche Begründung fehlte oft.

Microservices ermöglichen unabhängige Entwicklung, Deployment und Skalierung. Das ist sinnvoll, wenn unterschiedliche Teams an verschiedenen Teilen arbeiten, wenn diese Teile unterschiedliche Lebenszyklen haben, wenn sie unterschiedlich stark genutzt werden. Für ein kleines Team mit einem überschaubaren System ist ein Monolith oft die bessere Wahl.

“40 Prozent der Microservices-Implementierungen bringen keinen operativen Nutzen, zeigt der Morgan Stanley Report.”

Trotzdem entscheiden sich Teams für Microservices, ohne diese Fragen zu stellen. Der Morgan Stanley Report zeigt, dass 40 Prozent der Implementierungen keinen operativen Nutzen bringen. Die Komplexität verteilter Systeme, Netzwerk-Latenz, Eventual Consistency, Debugging über Servicegrenzen, wird übernommen ohne dass sie durch einen fachlichen Nutzen gerechtfertigt wäre.

Ähnlich verhält es sich mit Design-Prinzipien. DRY, SOLID und Clean-Code werden als universelle Gesetze behandelt. DRY besagt, dass jede Information im System nur einmal repräsentiert sein sollte. Das klingt einleuchtend. In der Praxis führt die dogmatische Anwendung oft zu falschen Abstraktionen.

Nehmen wir zwei Codestellen, die ähnlich aussehen:

// Versicherungs-Service: Prämienkalkulation
function calculatePremium(age, riskFactor, coverage) {
  return baseRate * (1 + (age / 100)) * riskFactor * coverage;
}

// HR-Service: Bonus-Berechnung
function calculateBonus(salary, performanceRating, yearsInCompany) {
  return salary * (1 + (performanceRating / 100)) * (1 + (yearsInCompany / 50));
}

Codebeispiel: Tobias Müller, Montag, 16.02.2026, 21:42 Uhr

Ein DRY-dogmatiker würde sie abstrahieren. Aber Prämienkalkulation folgt Versicherungs-Regelwerk, Bonusberechnung HR-Strategie. Die Abstraktion würde ein fremdes Coupling erzeugen. DRY ohne fachlichen Kontext führt zu Komplexität statt Vereinfachung.

Dasselbe gilt für Test-Coverage. 100 Prozent Coverage bedeutet nicht automatisch bessere Software. Die IBM-Studie zeigt, dass die Korrelation zwischen Coverage und Qualität schwach ist. Ein System mit 100 Prozent Coverage kann fachlich wertlos sein, wenn die Anforderungen missverstanden wurden.

Meiner Erfahrung nach ist dieser Abschnitt der Augenöffner. Viele Entwickler haben solche Entscheidungen getroffen, ohne die fachlichen Implikationen zu hinterfragen.

Die Akademisierung der Fachlichkeit: Wenn selbst DDD zum Selbstzweck wird

Domain-Driven Design sollte die Fachlichkeit in den Mittelpunkt stellen. Eric Evans‘ ursprüngliche Idee: Verstehe die Domäne und sprich die Sprache des Business. Heute wird DDD oft als Katalog von Patterns diskutiert.

Community-Diskussionen auf InfoQ oder Reddit zeigen, dass Entwickler über Aggregates und Entities reden, statt mit Fachexperten zu sprechen. Bounded-Context-Diagramme werden gezeichnet, statt die Grenzen aus der Domäne abzuleiten. Die Patterns werden auswendig gelernt, statt die Domäne zu verstehen.

“Selbst ein Ansatz wie DDD, der explizit den Fachfokus propagiert, wurde in etwas Technisches verwandelt.”

Das ist bezeichnend. Der Sog der Technologie ist so stark, dass er selbst Gegenbewegungen vereinnahmt.

Event-Storming und Domain-Storytelling können helfen, die Fachlichkeit zu verstehen. Aber auch sie werden zum Selbstzweck, wenn sie nicht konsequent auf die Domäne ausgerichtet sind.

Ich denke, dieser Abschnitt provoziert. Er zeigt, dass es keine einfache Lösung gibt. Nicht einmal DDD. Die Lösung liegt in der Haltung, nicht in der Methode.

Software als Werkzeug: Wie wir den Fokus zurück auf die Fachlichkeit lenken

Die Lösung liegt nicht in neuen Tools oder Methoden. Sie liegt in einer Haltungsänderung. Golo Roden plädiert dafür, weniger über Frameworks zu reden und mehr über Probleme.

Die Frage, die wir uns stellen sollten: Hilft das, das fachliche Problem besser zu lösen? Wenn ja, machen wir weiter. Wenn nein, sollten wir innehalten.

Bei Memoro war es wichtiger, die fachlichen Zusammenhänge der Daten richtig zu verstehen, als ob wir GraphQL oder REST nutzen. Bei compan.one war die Integrationslogik das fachliche Kernproblem, nicht die Frontend-Architektur.

Domain-Storytelling, Event-Storming und regelmäßige Gespräche mit Fachexperten können helfen. Aber sie dürfen nicht zum Selbstzweck werden.

Die Balance zwischen technischer Sauberkeit und Fachlichkeit ist entscheidend. Beide Aspekte sind wichtig, aber die Priorisierung muss stimmen. Erst das Problem verstehen, dann die Lösung bauen.

Cite this article

Tobias Müller (2026): Der Technologie-Tunnelblick: Warum wir lieber über Frameworks reden. https://ispringen.dev Lizenz: CC BY 4.0 – Namensnennung erforderlich.

Quellen