Moin,
ich beschäftige mich momentan mit der Neukonzeptionierung der Software eines Buchgroßhandels. Da die alte Software praktisch kein nennenswertes Domain-Model hat (simple Top-Bottom-Scripte und Funktionen machen mit der Datenbank was sie wollen) besitzt, dachte ich mir dass es an der Zeit ist das ganze "ordentlich" anzugehen.
Was Domain-Driven-Design ist war mir schon vorher bekannt, allerdings kam ich bisher noch nicht in die Verlegenheit das auch anwenden zu müssen, weswegen sich mir einige Probleme stellen welche ich mit reiner Recherche selber nicht lösen könnte.
Meine Recherchen zu dem Thema (Threadtitel) haben bisher ergeben dass, wenn man in dieses Problem läuft, ein Designfehler im Model vorliegt. Vielleicht kann mich hier ja jemand in die richtige Richtung schubsen.
Anforderungen:
Um den Rahmen des Threads nicht zu sprengen reduziere ich die Anforderungen auf das Nötigste um mein Problem zu veranschaulichen.
- Es sollen Bücher verkauft werden können. Die Exemplare verteilen sich auf mehrere Läger und Lagerplätze. Die Exemplare eines jeden Buches können sich beliebig auf unterschiedlichen Lagerplätzen befinden.
- Wenn ein Buch bestellt wird soll geprüft werden ob ausreichend Exemplare über alle Läger und Lagerplätze vorhanden sind.
- Ist das nicht der Fall soll die mögliche Lieferanzahl der Auftragsposition um die fehlende Anzahl von Exemplaren verringert werden.
- Sind genug Exemplare vorhanden sollen diese Exemplare im Lager als verkauft markiert werden.
- Außerdem muss nachvollzogen werden können welche Auftragsposition ihre Exemplare von welchen Lagerplätzen erhalten soll.
Bisheriger Lösungsansatz:
Auch wenn es sich aus den Anforderungen so herauslesen ließe sind Buchexemplare keine eigenen Entitäten. Auf einer Palette von Büchern, welche auf einen Lagerplatz geschoben wird, sind alle Bücher mit derselben ISBN als identisch anzusehen.
Läger und Lagerplätze müssen unabhängig davon, ob sich nun Buchexemplare darauf befinden oder nicht existieren können.
Das Lager muss mMn. als Aggregate-Root implementiert werden. Über das Aggregat werden dann die Lagerplätze als lokale Entities verwaltet deren ID der Name des Lagerplatzes als Value-Object ist.
Der Lagerplatz könnte dann wiederum die Lagerbestände als Value-Objects verwalten.
Auf der anderen Seite haben wir den Auftrag als Aggregate-Root und seine Auftragspositionen als Value-Objects.
Wird nun auch Buch bestellt übergeben wir dieses mit einer Bestellmenge an das Auftrags-Aggregat welches daraus eine neue Auftragsposition formen kann.
Was mache ich aber nun mit den Bedingungen für den Lagerbestand?
Ich kann wohl nicht einfach alle Läger an die Bestell-Methode des Auftrags übergeben und dieser dann das Finden der Bestände überlassen.
Lösung 1: Ich modelliere den Bestellprozess über einen Service. Theoretisch könnte dann aber ein anderer Service die Regeln des Lagerbestandes ignorieren.
Lösung 2: Ich implementiere ein Domain-Event für das Erzeugen einer neuen Bestellposition auf welches das Lager reagieren kann. Dann habe ich aber "nur" eine "indirekte" Kopplung zwischen Lager und Auftrag. Was passiert wenn ein Event fehlschlägt?
Problem: So oder so zieht der Prozess Änderungen in zwei Aggregaten mit sich. Da eine Transaktion aber immer nur ein Aggregat umfassen darf könnte der Persistierungsvorgang eines Aggregates fehlschlagen was zu einer Dateninkonsistenz führt welche über das Domain-Model ja gerade verhindert werden soll.
Lösung 3: Gesetzt dem Fall ich überlasse dem Auftragsaggregat das Finden der Bestände könnte ich ein Value-Object erzeugen welches die Referenz auf das Lager, das Value-Object Lagerplatz und die Liefermenge enthält. Dadurch modelliere ich aber nur den Soll-Zustand, d.h. es kann Doppelverkäufe geben da das Lager nichts über die geplanten Liefermengen weiß und der nächste Bestellprozess die bereits als verkauft markierten Exemplare nicht berücksichtigen kann.
Lösung 4: Ich modelliere den Lagerbestand in das Auftragsaggregat hinein. Das ist aber per se schon Quatsch da auf lange Sicht gesehen natürlich nicht nur das Auftragswesen mit den Lagerbeständen interagieren muss.
Ich wäre sehr dankbar wenn mich jemand in die richtige Richtung schubsen könnte.
ich beschäftige mich momentan mit der Neukonzeptionierung der Software eines Buchgroßhandels. Da die alte Software praktisch kein nennenswertes Domain-Model hat (simple Top-Bottom-Scripte und Funktionen machen mit der Datenbank was sie wollen) besitzt, dachte ich mir dass es an der Zeit ist das ganze "ordentlich" anzugehen.
Was Domain-Driven-Design ist war mir schon vorher bekannt, allerdings kam ich bisher noch nicht in die Verlegenheit das auch anwenden zu müssen, weswegen sich mir einige Probleme stellen welche ich mit reiner Recherche selber nicht lösen könnte.
Meine Recherchen zu dem Thema (Threadtitel) haben bisher ergeben dass, wenn man in dieses Problem läuft, ein Designfehler im Model vorliegt. Vielleicht kann mich hier ja jemand in die richtige Richtung schubsen.
Anforderungen:
Um den Rahmen des Threads nicht zu sprengen reduziere ich die Anforderungen auf das Nötigste um mein Problem zu veranschaulichen.
- Es sollen Bücher verkauft werden können. Die Exemplare verteilen sich auf mehrere Läger und Lagerplätze. Die Exemplare eines jeden Buches können sich beliebig auf unterschiedlichen Lagerplätzen befinden.
- Wenn ein Buch bestellt wird soll geprüft werden ob ausreichend Exemplare über alle Läger und Lagerplätze vorhanden sind.
- Ist das nicht der Fall soll die mögliche Lieferanzahl der Auftragsposition um die fehlende Anzahl von Exemplaren verringert werden.
- Sind genug Exemplare vorhanden sollen diese Exemplare im Lager als verkauft markiert werden.
- Außerdem muss nachvollzogen werden können welche Auftragsposition ihre Exemplare von welchen Lagerplätzen erhalten soll.
Bisheriger Lösungsansatz:
Auch wenn es sich aus den Anforderungen so herauslesen ließe sind Buchexemplare keine eigenen Entitäten. Auf einer Palette von Büchern, welche auf einen Lagerplatz geschoben wird, sind alle Bücher mit derselben ISBN als identisch anzusehen.
Läger und Lagerplätze müssen unabhängig davon, ob sich nun Buchexemplare darauf befinden oder nicht existieren können.
Das Lager muss mMn. als Aggregate-Root implementiert werden. Über das Aggregat werden dann die Lagerplätze als lokale Entities verwaltet deren ID der Name des Lagerplatzes als Value-Object ist.
Der Lagerplatz könnte dann wiederum die Lagerbestände als Value-Objects verwalten.
Auf der anderen Seite haben wir den Auftrag als Aggregate-Root und seine Auftragspositionen als Value-Objects.
Wird nun auch Buch bestellt übergeben wir dieses mit einer Bestellmenge an das Auftrags-Aggregat welches daraus eine neue Auftragsposition formen kann.
Was mache ich aber nun mit den Bedingungen für den Lagerbestand?
Ich kann wohl nicht einfach alle Läger an die Bestell-Methode des Auftrags übergeben und dieser dann das Finden der Bestände überlassen.
Lösung 1: Ich modelliere den Bestellprozess über einen Service. Theoretisch könnte dann aber ein anderer Service die Regeln des Lagerbestandes ignorieren.
Lösung 2: Ich implementiere ein Domain-Event für das Erzeugen einer neuen Bestellposition auf welches das Lager reagieren kann. Dann habe ich aber "nur" eine "indirekte" Kopplung zwischen Lager und Auftrag. Was passiert wenn ein Event fehlschlägt?
Problem: So oder so zieht der Prozess Änderungen in zwei Aggregaten mit sich. Da eine Transaktion aber immer nur ein Aggregat umfassen darf könnte der Persistierungsvorgang eines Aggregates fehlschlagen was zu einer Dateninkonsistenz führt welche über das Domain-Model ja gerade verhindert werden soll.
Lösung 3: Gesetzt dem Fall ich überlasse dem Auftragsaggregat das Finden der Bestände könnte ich ein Value-Object erzeugen welches die Referenz auf das Lager, das Value-Object Lagerplatz und die Liefermenge enthält. Dadurch modelliere ich aber nur den Soll-Zustand, d.h. es kann Doppelverkäufe geben da das Lager nichts über die geplanten Liefermengen weiß und der nächste Bestellprozess die bereits als verkauft markierten Exemplare nicht berücksichtigen kann.
Lösung 4: Ich modelliere den Lagerbestand in das Auftragsaggregat hinein. Das ist aber per se schon Quatsch da auf lange Sicht gesehen natürlich nicht nur das Auftragswesen mit den Lagerbeständen interagieren muss.
Ich wäre sehr dankbar wenn mich jemand in die richtige Richtung schubsen könnte.
Kommentar