Architekturanalyse und Implementierung von Domain Driven Design

worked on by: Tom Lausmann

Outline

In Softwareunternehmen kommt es immer wieder einmal vor, dass die Zeit eng wird. Sei es durch eine zu eng gesetzte Deadline oder durch sprunghaft wechselnde Anforderungen, die nicht mehr zur vorhandenen Codebasis passen. Durch diese Umstände und die eventuell nicht vorhandene Erfahrung der Entwickler, wurden neue Anforderung in eine ungenügenen Qualität umgesetzt. Dadurch leidet die Architektur des Systems. Fachlichkeiten kommen durcheinander und es entstehen Abhängigkeiten zu Komponenten, die so nicht vorgesehen waren. Kommen diese Umstände öfter vor, ohne dass deren Folgen bereinigt werden, wird das Projekt immer schlechter wartbar und die Implementierung neuer Features dauert immer länger.

In der Bachelor-Arbeit soll es darum gehen, ein Softwareprojekt, welches schon öfter in eine wie oben beschriebene Situation gekommen ist, wieder in eine bessere Bahn zu lenken. Dazu soll eine Refaktorisierung durchgeführt werden. .

Zunächst wird die Zielarchitektur bestimmt. Dazu soll sich überlegt werden, wer die Benutzer des Produktes sind und was sie gemeinsam haben. Daraus soll eine Modul-Struktur entstehen, die genau das repräsentiert. Die Module selber sollen homogen aufgebaut sein, sodass man sich in allen gleich zurecht finden kann. Diese innere Struktur ist ebenfalls zu bestimmten.

Ergebnis der Arbeit soll die Refaktorisierung von des Produktes zu der gewünschten Architektur. Dabei will ich die Werkzeuge von Domain-Driven Design benutzen, um zu bestimmen welche Module ich brauche, aus was für Bestandteilen sie bestehen und wie diese Organisiert sind.

Thesis Requirements

• Erstellung einer SOLL-Architektur und vergleich mit der IST-Architektur
• Herleitung der erforderlichen Refaktorisierungsschritte
• Umsetzung der Refaktorisierungen
• Bewertung der Refaktorisierung auf Validität und Praktikabilität

Milestones and Planning

1. Die SOLL-Architektur des Produkt wurde mit den Werkzeugen des DDD ermittelt

2. Die SOLL-Architektur wurde mit der IST-Architektur verglichen

3. Die ersten Refaktorisierungen wurden durchgeführt

4. Alle Refaktorisierungen wurden abgeschlossen

Weekly Status

Woche 1 (CW 25)

Activities

• Definition der Bounded-Contexts für das Produkt

Results

• Es gibt eine "Kern"-Domäne für das Produkt und jeweils einen Kontext für die jeweiligen Kunden

Next Steps

• Ermittlung der Entities, Aggregates und Value-Objects für die jeweiligen Kontexte

Problems

• Wie passt der stark technische teil in die Domain? (OCR, Segmentierung, Kalssifizierung, Konvertierung, …)

Weekly Status

Woche 3 (CW 27)

Activities

• Versuch, die Entitäten, die Eigenschaften mehrerer in ihre Kontexte aufzuteilen und in die entsprechenden Module zu verschieben.

Results

• Der Versuch ist gescheitert, weil das Modell momentan zu stark ineinander verworren ist

Next Steps

• Entfernen der Bidirektionalen Kopplung zwischen den Entitäten.

Problems

• Manche Services verwenden die Rückreferenz auf Eltern-Entitäten
• Kind-Entitäten können direkt von der Datenbank geladen werden, was das erste Problem verstärkt

Woche 5 (CW 29)

Activities

• Entfernen der Bidirektionalen Referenzen zwischen den Eltern- und Kind-Entitäten
• Bestimmung von Aggregaten und festlegen der Aggregat-Wurzeln
• Zugriff auf Entitäten ausschließlich über die Aggregat Wurzeln

Results

• Diese Refaktorisierung ist einfacher als erwartet, die Services, die Kind- und Elternentitäten Benutzen sind ehr rar und durch das übergeben der Eltern-Entität leicht wieder funktionstüchtig zu machen.
• Die Eigenschaften, die einem Kunden-Kontext zuzuordnen sind, jedoch in einer Entität stekcen, die dem Kern-Kontext angehört, wurden in ein Aggregat verschoben, dass den Kunden-Kontext repräsentiert

Next Steps

• Überdenken der momentanen Identitäten

Problems

• Externe Systeme greifen auf die Entitäten teilweise direkt über den Primärschlüssel der Datenbank zu. Das geschieht auch, wenn die Entität eine Kind-Entität ist. Dadurch muss validiert werden, dass die Kind-Entität auch wirklch der Eltern-Entität gehört

Woche 7 (CW 31)

Activities

• Umstellung der Identitäten

Results

• Die meisten Entitäten haben nun Ersatz-Identitäten: eine versteckte Technische Identität in Form der Datenbank-ID und eine fachliche Identität.
• Die Aggregat-Wurzeln haben eine globale Identität und die Kind-Entitäten eine lokale Identität, die einzigartig in Bezug auf das Aggregat ist

Next Steps

• Umstrukturierung der Service-Klassen
• Fachliche Logik soll zu den Entitäten wandern
• Technische Logik bleibt zwar in Services, die werden jedoch schmaler geschniten

Problems

• Die Service-Klassen haben teilweise viele Aufgaben
• Manche Fachlogik ist schwer direkt einer Entität zuzuordnen

Woche 9 (CW 33)

Activities

• Verschieben der technischen und fachlichen Logik
• Anwendung einer Paketstruktur aus einem DDD-Beispielprojekt

Results

• das Beispielprojekt hat eine gute Vorlage geliefert, die Klassen zu organisieren
• die Bestehenden Module wurden erst einmal auf diese Struktur angepasst

Next Steps

• Neuer Versuch, die neue Modulstruktur anzuwenden

Woche 10 (CW 34)

Activities

• Umsetzung der neuen Modulstruktur

Results

• Im vergleich zur ersten Woche, war die Refaktorisierung jetzt nahezu trivial, die Klassen waren innerhalb des Alten Moduls schon so aufgeteilt, sodass man sie nur noch verschieben musste