Home

Modularisierung von Software-Applikationen: Strategien und Vorgehen

Bei der Software-Modularisierung geht es darum, große monolithische Applikationen in kleinere, wartbare Module aufzuteilen. Die Zielumgebung kann, muss aber keine Containerumgebung sein.

Pyramide mit drei Ebenen: Fachlich, Architektur (Modularisierung in rot) und Technisch, daneben Prozesse und Organisation.

Das Problem mit monolithischen Enterprise-Applikationen

Entgegen der weitverbreiteten Meinung, dass Softwareprojekte nach einem initialen Release fertig sind, wachsen Enterprise-Applikationen kontinuierlich. Das führt oft dazu, dass die Systeme zunehmend träger und komplexer werden und Änderungen oder Erweiterungen immer mehr Zeit benötigen. Um wieder eine effiziente Softwareentwicklung zu erreichen, muss das System in kleinere, autonome Komponenten geteilt werden.

-> lese auch „Warum Software verrostet und wie wir gegen den Verfall ankämpfen.“

Software-Architektur und Organisationsstruktur

Nach dem Gesetz von Conway (Conway’s Law) spiegeln die Strukturen einer Applikation die Kommunikationsstrukturen der Organisation wider, die die Applikation entwickelt. Fundamentale Strukturen einer Applikation können demnach nicht geändert werden, ohne die Strukturen der Entwicklungsorganisation anzupassen.

Für die Modularisierung von Applikationen bedeutet das, dass gemeinsam mit der Aufteilung der Software auch die Neuorganisation von crossfunktionalen Teams einhergehen soll. Ein einfaches Aufteilen der bestehenden Teammitglieder in neue Teams funktioniert oft nicht. Die Herausforderung dabei sind Spezialisten-Rollen, die beispielsweise nur von einer Person ausgefüllt werden. Dafür müssen neue Konzepte für die agile Teamorganisation eingeführt werden. Überlegungen dazu sind nicht Teil dieses Artikels.

Optimale Größe von Software-Modulen: Wie groß ist zu groß?

Eine einzelne Applikation mit mehreren Millionen Codezeilen ist eindeutig zu groß für effiziente Softwareentwicklung, aber auch sehr viele kleine zusammenhängende Komponenten schaffen übermäßige Komplexität. Die Frage ist daher, was ein gutes Maß zwischen zu groß und zu klein ist.

Nach Conway’s Law schaffen Teamgrenzen auch Grenzen in der Software. Daraus leiten wir eine erste Größenordnung für Applikationsmodule ab:

Eine Applikation sollte so groß sein, dass sie von einem agilen Team von 5-9 Personen weitgehend autonom entwickelt werden kann.

Die Zahl von 5-9 Personen ist zum einen eine empfohlene Größe eines Scrum-Teams, ist aber auch konsistent mit Robert Dunbars Circle of Friends.

Diagramm mit mehreren konzentrischen Kreisen, die soziale Beziehungen von

Kriterien für die Modularisierung: Nach welchen Prinzipien aufteilen?

Nachdem wir eine ungefähre Vorstellung haben, wie groß ein Software-Modul bzw. ein eigenständiger Teil einer Anwendung sein soll, bilden wir Teams, die daran arbeiten werden. Aber nach welchen Kriterien sollen wir die Teams und Module strukturieren? Wie so oft gibt es verschiedene Ansätze, die je nach Kontext besser oder schlechter geeignet sind.

Unser Default-Ansatz ist Domain Driven Design (DDD) und damit eine Aufteilung der Teams in fachliche Domänen. Wir orientieren uns dabei an Geschäftsprozessen bzw. Wertschöpfungsketten und nicht an Entitäten. Eine gute Orientierung bieten auch Benutzergruppen. Hilfreich für die Kommunikation innerhalb des Teams ist, wenn die Teammitglieder gemeinsam an einem Standort arbeiten.

Das Diagramm zeigt zentrale Punkte einer Projektübersicht, darunter Fachliche Domänen, Risikofaktoren und Performance-Anforderungen.

Domänen-getriebene Modularisierung: Aufteilen in Fachdomänen

Diagramm zur strategischen Modellierung mit fünf Elementen: Anspruchsberechnung, Fremdleistungen, Geldleistungen, Stammdatenverwaltung und Kontenverwaltung.

Nachdem wir eine klare Vorstellung davon haben, welche Größe die Teams haben sollen und wenn wir beispielsweise aufgrund von Budgetüberlegungen wissen, wie viele Teams wir bereitstellen können, müssen wir uns mit der fachlichen Aufteilung des Systems in Domänen befassen. Ziel ist es, eine Domänen-Karte (Domain Map) zu erstellen, in der die fachlichen Domänen, ihre Hauptaufgaben und ihre Abhängigkeiten untereinander dargestellt sind.

Wichtig ist, dass keine Zyklen in den Abhängigkeiten auftreten. Das bedeutet nicht, dass keine Serviceaufrufe in entgegengesetzte Richtungen stattfinden dürfen, sondern die Abhängigkeiten (Pfeile) bestimmen, wer die Schnittstellen definiert und wer sie nutzt.

Modularisierung implementieren: Praktische Umsetzung

Ziel der Software-Modularisierung ist eine grundsätzliche Zuordnung: 1 Domäne – 1 Team – 1 Applikation.

Anmerkung: In der Praxis gibt es immer wieder Gründe, davon abzuweichen. Insbesondere am Beginn einer Modularisierungsinitiative ist diese Aufteilung nicht gegeben.

Am Beginn der Modularisierungsinitiative ordnen wir einer Domäne ein Team zu und beginnen am Monolithen zu arbeiten. Gemäß Conway’s Law erwarten wir, dass dadurch die Aufteilung des Monolithen unterstützt wird. Beim Vorgehen gibt es unterschiedliche Ansätze, die auch kombiniert werden können. Gemeinsam ist allen Ansätzen, dass in kleinen Schritten iterativ mit ständiger Reflexion vorgegangen wird.

Strategische Modularisierung: Top-Down Ansatz

Diagramm mit Kästen und Pfeilen, das einen Prozess des strategischen Redesignt sowie den Container darstellt.

Bei diesem Ansatz werden zuerst kleine Teile aus der bestehenden Applikation als eigenständige Komponenten (z.B. Container, Microservices) herausgebrochen. Danach werden die Komponenten schrittweise erweitert.

Dieser strategische Ansatz ist speziell dann geeignet, wenn:

Die Domänenaufteilung bereits ausgereift ist
Viele neue Anforderungen im Greenfield-Bereich bestehen
Geschäftsprozesse neu entwickelt werden sollen
Gutes Wissen zur Zielarchitektur (Container, Kubernetes, Cloud-native) vorhanden ist

Taktische Modularisierung: Bottom-Up Ansatz

Diagramm zeigt den Unterschied zwischen taktischem und strategischem Redesign mit Pfeilen und Container-Format.

Bei diesem Ansatz werden zuerst innerhalb der bestehenden Applikation klare Grenzen und Schnittstellen etabliert. Danach werden Komponenten entlang der definierten Grenzen schrittweise herausgelöst.

Dieser taktische Ansatz ist speziell dann geeignet, wenn:

Domänengrenzen noch nicht klar definiert sind und sich erst entwickeln
Viel bestehender Legacy-Code vorhanden ist
Prozesse bereits ausgereift sind
Wissen über die Zielarchitektur (Container) erst aufgebaut wird oder
Die technische Architektur nicht grundsätzlich geändert werden soll
Die Ressourcen beschränkt sind und nur langsames, inkrementelles Vorgehen möglich ist

Langfristige Perspektive: Kontinuierliche Softwaremodernisierung

Wie bei allen Themen der Softwaremodernisierung ist auch Modularisierung kein Einmalprojekt, das nach Fertigstellung abgehakt werden kann. Software-Module wachsen und Teams sind ständigem Wandel unterworfen. Daher sollte dem Modularisierungsaspekt der Software regelmäßig Aufmerksamkeit gewidmet werden und eine kontinuierliche Architektur-Evaluation stattfinden.