User Tools

Site Tools


technology:domainmodel:aggregatedesign

This is an old revision of the document!


Aggregate Design

Beispiel Projektstruktur

Angenommen, man ändert was am blau eingefärbten Projekt. Es wird Regeln geben, die einzuhalten sind, z.B. dass ein internes Projekt kein externes Projekt als Teilprojekt haben darf1). Abhängig der Regel, müssen unterschiedlich viele andere Projekte betrachtet werden, um die Regel einzuhalten.

  1. Es gibt Regeln, für deren Einhaltung man die gesamte Projektstruktur benötigt:
    • Ein Projekt darf nur einmal in der Struktur hängen2)
    • Die Projektnummer muss eindeutig sein
  2. Es gibt Regeln, für deren Einhaltung man die Struktur innerhalb eines Hauptknoten braucht,
  3. Es gibt Regeln, für die man nach unten gucken muss,
  4. Es gibt Regeln, für die man nach oben gucken muss.

Das Problem bei dieser Betrachtung ist, dass man die Projektstruktur strukturell angeht3). Ein Domänenmodell soll aber das gewünschte Verhalten der Domäne bedienen. Was soll die Projektstruktur hergeben?

Verhaltenssicht

  1. Ich möchte ein neues Hauptprojekt anlegen können,
  2. Ich möchte ein neues Teilprojekt zum Hauptprojekt anlegen können,
  3. Die Projektnummer soll automatisch vergeben werden, wenn ich das Projekt anlege oder freigebe,
  4. Die Projektnummernvergabe soll das darüber liegende Projekt mit einbeziehen,
  5. Die Projektnummer soll global eindeutig sein,
  6. Angaben des darüber liegenden Projektes sollen automatisch im darunter liegenden Projekt aufgenommen werden, bei Anlage des Teilprojektes oder bei späteren Änderungen im Projekt darüber,
  7. Aus einem Teilprojekt soll ein Hauptprojekt werden können,
  8. Ein Hauptprojekt soll zum Teilprojekt eines anderen Projektes werden können,
  9. Ebenso ein Teilprojekt

Es stellt sich die Frage nach der Sinnhaftigkeit dieser geforderten Flexibilität. Wie kann man das System immer noch genauso flexibel für den Anwender halten, trotzdem hier und da ein paar Punkte anders lösen. Wenn z.B. bereits Zeiten auf einen Vorgang4) eines Teilprojektes gebucht wurden, stellt sich die Frage, ob man das Teilprojekt einfach beliebig verschieben können soll, womöglich in ein komplett anderes Hauptprojekt eines anderen Kunden.

Eine Frage wäre z.B., ob die Punkte 7. bis 9. nicht besser gelöst werden können, indem man Projekte einfach kopieren kann. Dann kann man ein Hauptprojekt Gehen wir die Punkte mal einzeln durch

  1. dfas

Globales Aggregate für die Projektstruktur

Die Projektstruktur sieht beispielhaft aus wie folgt:

Wenn ein Projekt innerhalb der Struktur verschoben wird, wird die Struktur als Ganzes gesperrt, und es wird geprüft, dass es keine Zirkel gibt. Zirkel kann es geben, wenn Projekt 1 unter Projekt 2 gehängt wird, und gleichzeitig Projekt 2 unter Projekt 1 gehängt wird. Wenn nicht der gesamte Baum gesperrt wird, wären die beiden Aktionen isoliert von einander, und mit Read Committed oder einer andere Art von Abfrage des schließlich konsistenten Lesemodells könnte das während der Prüfung durch rutschen, solange beide Prüfungen beider Aktionen passieren noch bevor eine der beiden fertig ist5).

Möchte man eine global konsistente Sicht auf die Baumstruktur, dann muss die Baumstruktur auch global gesichert werden, d.h. ein universelles Aggregate werden6). Das hat Vorteile, weil es einfach zu handhaben ist. Es hat aber auch Nachteile, denn die Parallelität der Domäne kann darunter leiden.

Ein Aggregate pro Hauptprojekt

Man könnte das globale Aggregate aufteilen auf kleinere Aggregates, und zwar eines pro Hauptprojekt. Das würde dann in etwa so aussehen:

In diesem Fall sind die einzelnen Hauptprojektstrukturen von einander isoliert. Solange ein Projekt die Struktur nicht wechselt, bietet das wiederum eine global konsistente Sicht auf die Domäne, da die Strukturen völlig unabhängig von einander existieren. Das erreicht man, indem man das Projekt zu einer Entität innerhalb des Struktur-Aggregates macht. Ist ein Projekt aber selbst ein Aggregate, und wird nur von der Struktur referenziert, und erlaubt man dem Projekt einen Wechsel von einer Struktur in eine andere, dann ist die globale Sicht nicht mehr konsistent, maximal schließlich konsistent.

Man muss immer daran denken, dass die globale Sicht die Summe der Sichten auf die einzelnen Aggregates ist, und dass die Reihenfolge, in der diese Sicht aufgebaut wird, bzw. in der die Aggregate Sichten mit einbezogen werden, nicht global ist. Wenn somit Projekt 1 von Struktur A in Struktur B verschoben wird, könnte es sein, dass die globale Sicht temporär die Ereignisse von Struktur B beinhaltet, in der das Projekt hinzugefügt wurde, aber noch nicht die Ereignisse von Struktur A in der das Projekt aus der Struktur entfernt wurde7). In der globalen Sicht wäre das Projekt somit temporär gleichzeitig in zwei Strukturen enthalten.

Projekt als Entität in einem Hauptprojekt

Eine konsistente Sicht erhält man, wenn man ein Projekt zu einer Entität einer Projektstruktur macht. Dann kann das Projekt nicht in eine andere Struktur verschoben werden, womit meine Kunden nun bereits über 10 Jahre lang leben8).

Es ist aber irgendwie eine merkwürdige Sicht, ein Projekt nur als Entität einer Projektstruktur zu sehen. Wenn wir die Struktur aber nun das Projekt nennen, und die darin enthaltenen Entitäten Teilprojekte, wäre das schon verständli

1) weil das wenig Sinn hat
2) wenn die Struktur ein Projekt lediglich referenziert
3) was der Name ja im Grunde andeutet
4) hätten wir es doch damals Arbeitspaket genannt!
5) Connection.Commit
6) pro Mandant
7) nicht vergessen, jedes Aggregate hat eine eigene, isolierte Sicht auf das Geschehene
8) und nicht einmal nach der Möglichkeit gefragt haben, ein Projekt unter ein anderes Hauptprojekt zu hängen
technology/domainmodel/aggregatedesign.1361377639.txt.gz · Last modified: 2013/02/20 17:27 by rtavassoli