Kopplung ist ein Balance-Akt. Zu viel Kopplung reduziert die Delivery-Geschwindigkeit und Wartbarkeit. Keine bis wenig Kopplung ist unrealistisch. In dieser Episode des INNOQ Podcasts diskutieren Sven Johann und Erik Wilde über diesen Balance-Akt, Arten der Kopplung, Hyrum's Law, API Design und das Bezos Mandate. Ein Gespräch über Kopplung als strategisches Designprinzip.
--------
1:03:01
--------
1:03:01
Evolution von Teamstrukturen – Teil 2
Widerstände, Unklarheiten und dysfunktionale Zusammenarbeit: Viele Probleme zeigen sich erst, wenn Teamstrukturen aktiv verändert werden. In dieser Fortsetzung zu „Evolution von Teamstrukturen“ sprechen Anja Kammer und Jakob Oswald über typische Herausforderungen bei der Arbeit mit Team Topologies: Enabling Teams, die Vorgaben machen statt zu unterstützen. Plattform-Teams, die den Kontakt zu ihren Nutzer:innen verlieren. Entwicklungsteams, die mit neuer Betriebsverantwortung allein bleiben. Eine Folge über die Praxis hinter dem Modell – und darüber, was hilft, wenn Veränderungen nicht wie gewünscht greifen.
--------
51:33
--------
51:33
Kohäsion
In dieser Episode des INNOQ Podcasts sprechen Michael Plöd und Sven Johann über ein Prinzip, das in der Softwarearchitektur oft genannt, aber selten genauer betrachtet wird: Kohäsion. Ausgehend von den sieben Kohäsionsarten nach Stevens, Myers und Constantine geht es um die Frage, was Module inhaltlich zusammenhält – und wie sich sinnvolle Grenzen ziehen lassen. Im Mittelpunkt steht der fachliche Zweck als Orientierung für Strukturentscheidungen. Sie sprechen über praktische Beispiele, über Methoden wie Domain-driven Design, Event Storming und die Bounded Context Canvas – und über die Möglichkeiten und Grenzen von Metriken wie LCOM.
--------
1:09:10
--------
1:09:10
Testpyramide oder Testdiamant?
In dieser Episode des INNOQ Podcasts diskutieren Daniel Westheide, Jakob Oswald und Sven Johann über das Für und Wider verschiedener Teststrategien. Ausgehend von einer internen Debatte bei INNOQ gehen die drei der Frage nach, wie viel Gewicht auf Unit Tests, Integrationstests oder exploratives Testen gelegt werden sollte – und was die Domäne damit zu tun hat. Sie sprechen über transaktionale Fallstricke, überflüssige Redundanz durch überambitionierte Testabdeckung und persönliche Erfahrungen aus regulierten Projekten. Am Ende steht kein Dogma, sondern ein differenziertes Bild: zwischen Testpyramide, Testdiamant und gesundem Pragmatismus.
--------
1:08:05
--------
1:08:05
Jetzt doch wieder ein Monolith/Modulith?
Im Podcast diskutieren Torsten Mandry und Sven Johann Überlegungen und Erfahrungen für oder gegen eine Microservices-Architektur bzw. einen Modulithen. Während Microservices oft wegen ihrer Unabhängigkeit und Entkopplung geschätzt werden, zeigen sich auch Nachteile, etwa durch erhöhten Schnittstellenaufwand, komplexes Deployment und Infrastruktur. Torsten beschreibt, wie er durch ein eigenes Experiment mit einem Modulith herausfinden wollte, ob und wie Modularisierung ohne Microservices gelingen kann. Die beiden diskutieren die Abwägungen dieser Entscheidung – abhängig von Teamgröße, Projektphase, technischen Anforderungen und strategischer Planung.