Requirements-Engineering - Designmethoden

Wie können wir aus groben Zielen und Vorgaben die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse (Use Cases) untersuchen? Wenn wir in der Softwareentwicklung über fachliche Anforderungen sprechen wollen, sprechen wir am Besten in der Sprache der Fachexperten. In der Sprache des Kunden! Dafür müssen Entwickler, Product Owner und Projektleiter die Fachsprache erlernen. Dieser Ansatz nennt sich Domain-Driven-Design (DDD).

Domain-Driven-Design (DDD) - Modellierung nach Fachlichkeit

Der Grundsatz dieser Methode lässt sich kurz zusammenfassen: "Wir konzentrieren uns ausschließlich auf den fachlichen Teil eines Themas und nicht auf mögliche technische Lösungen." Als Hilfsmittel zur Modellierung sei hier auf das Domain Storytelling verwiesen!

Was sind eigentlich die Vorteile des DDD?

• Die Kommunikation zwischen Fachexperten und Entwicklerteam ist frei von Störungen, denn es kann direkt über Prozesse, Abläufe oder Funktionen eingestiegen werden
• Fachexperten können Ihre Anforderungen präziser formulieren, da sie sich in ihrer Fachdomain befinden

Requirements-Engineering - Designmethoden

Wichtig beim Ansatz der Modellierung nach Fachlichkeit ist die Erarbeitung eines gemeinsamen Sprachschatzes (Glossar) auf Basis der Ubiquitous Language. Dieses Glossar ist die Grundlage der gemeinsamen Projektsprache - Kommunikation zwischen Entwickler, Product Owner, Projektleiter und Fachexperten. Als Hilfsmittel zur Modellierung gibt es unterschiedliche Werkzeuge, hier sei eines dieser genannt: wps.de

Strategisches Design - Bounded Context (BC)

Beim strategischen Design ordnen wir Fach-/Themengebiete die inhaltlich zusammengehören (Bounded Context). Wichtig hierbei ist die Klassifizierung und Dokumentation der Begrifflichkeiten pro Bounded Context.

Kontextbetrachtung am Beispiel Softwareentwicklung

• Softwareentwicklung als Zentrum, hier findet die eigentliche Softwareentwicklung statt. 
• Anforderungen identifizieren
• Entwürfe ausarbeiten
• Anforderungen implementieren
• Automatisierte Tests der Implementierung
• Third-Level-Support
• ...
• Rechnungswesen
• Geschäftsbuchführung
• Kosten- und Leistungsrechnung
• Statistik
• Planungsrechnung
• Informationsaufgabe
• ...
• Vetrieb/Marketing
• Aufbau eines Kundenstammes
• Pflege der bestehenden Kundenbeziehungen
• Vorschläge zur Produktentwicklung
• ...
• Support
• Klassifizieren von Kundenanfragen
• Klassifizierung und Fehlern
• ..
• Buchhaltung
• Bearbeitung der Transaktionen
• Verfassen von Steuererklärungen
• Verfassen von Lohnabrechnungen
• Prüfung, Kontierung und Verbuchung von laufenden Geschäftsvorfällen
• ...

Zusammengehörige Fach-/Themengebiete zu ordnen ist das eine, aber wie gehen wir mit "Bounded Context" um? Die Antwort kommt prompt: Wir modellieren granulare Basisbausteine (Taktisches Design).

Taktisches Design

Taktisches Design oder auch Tactical Pattern genannt ist eine Reihe von Entwurfsmustern und Bausteinen, mit denen domänengesteuerte Systeme entworfen werden können. Selbst Projekte die nicht domänengesteuert sind, können von der Verwendung einiger taktischer DDD-Muster profitieren. 

Welche taktischen Werkzeuge stehen uns hier zur Verfügung?

Werkzeug	Beschreibung
Value-Objects	Ein Value-Object ist ein Objekt, dessen Wert von Bedeutung ist. Dies bedeutet, dass zwei Wertobjekte mit genau demselben Wert als dasselbe Wertobjekt betrachtet werden kann und somit austauschbar sind. Aus diesem Grund sollten Wertobjekte immer unveränderlich gemacht werden. Anstatt den Status des Wertobjekts zu ändern, ersetzen wir es durch eine neue Instanz. Wir verwenden hier für komplexe Wertobjekte das BuilderPattern. Ein Value-Object darf niemals Entitäten beinhalten.
Entities	Eine Entität ist ein Objekt, dessen Identität von Bedeutung ist. Um die Identität einer Entität bestimmen zu können, verfügt jede Entität über eine eindeutige ID, die beim Erstellen der Entität zugewiesen wird und während der gesamten Lebensdauer der Entität unverändert bleibt. Sie stellt die Kernkomponente einer Fachdomäne dar.
Domain Events	Ein DomainEvent ist alles, was im Domänenmodell passiert und für andere Teile des Systems von Interesse sein kann. DomainEvents können grobkörnig sein (z. B. wird ein bestimmtes Aggregat erstellt oder ein Prozess gestartet) oder feinkörnig (z. B. wird ein bestimmtes Attribut eines bestimmten Aggregat geändert).
Domain Services	In seiner einfachsten Form kann ein DomainService eine Dienstprogrammklasse mit einer statischen Methode sein. Weiterführende DomainServices können als Singletons implementiert werden, in die andere Domänendienste und Repositorys eingefügt sind.

Im Vergleich zu strategischem domänengesteuertem Design ist taktisches Design viel praktischer und näher am eigentlichen Code. Strategisches Design befasst sich mit abstrakten Ganzen, während taktisches Design sich mit Klassen und Modulen befasst. Der Zweck des taktischen Entwurfs besteht darin, das Domänenmodell so zu verfeinern, dass es in Arbeitscode konvertiert werden kann.