This is an old revision of the document!
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.
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?
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
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.
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.
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