tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Die Projektstruktur in PRO•M ======
Die Projektstruktur in PRO•M ist hierarchisch:
{{ :applications:prom:projectstructure.png?nolink |}}
Wenn wir DDD((Domain Driven Design)) anwenden, müssen wir innerhalb dieser Struktur [[technology:domainmodel:aggregate|Aggregates]] identifizieren und definieren. In der Delphi 6.0 Entwicklung war das einzelne Projekt das Aggregate, und für bestimmte Änderungen wurde UOW((Unit of Work)) verwendet, indem mehrere Projekte gemeinsam in eine Transaktion behandelt wurden. Wird z.B. Projekt 1.1.2 von Projekt 1.1 entfernt und unter Projekt 1.2 gehängt, werden alle 3 Projekte //gesperrt//. Es wird dann geprüft, ob Projekt 1.1.2 kein //Vorfahr// von Projekt 1.2 ist, weil es ansonsten einen Zirkel gibt((Wenn Projekt 1.1.2 ein Vorfahr von Projekt 1.2 ist, und dann Projekt 1.2 zum Vorfahr von Projekt 1.1.2 gemacht wird, haben wir einen Zirkelbezug)).
\\ \\
Es wird aber auch geprüft, ob Projekt 1.2 noch keine Vorgänge unter sich hängen hat. Dafür werden dann die Projekte 1.2.1. und 1.2.2 auch noch gesperrt((Und das ist auch gar nicht 100% sicher, weil jemand anderes parallel einen Vorgang unter Projekt 1.2 hängen könnte)).
\\ \\
Wenn also Projekt 1.1.2 unter Projekt 1.2 gehängt wird, werden folgende Projekte gesperrt:
{{ :applications:prom:lockingforprojectmove.png?nolink |}}
Das bedingt eine Transaktion, bzw. ein UOW((Unit of Work)). Dafür müssen alle Projekt auch in einem //Dataspace// leben, ansonsten müsste man eine verteilte Transaktion für den UOW verwenden, etwas das spätestens seit [[http://cs.brown.edu/courses/csci2270/archives/2012/papers/weaker/cidr07p15.pdf|Pat Hellands Artikel]] vermieden werden sollte.
===== Identifizieren von Aggregates für die Projektstruktur =====
==== Das System/Der Mandant als Aggregate Root ====
Das System könnte für die Projektstruktur verantwortlich sein:
{{ :applications:prom:systemasprojectstructureaggregateroot.png?nolink |}}
Vorteile:
  * Zirkelbezüge können strikt vermieden werden
  * Das //Read Model// ist immer konsistent
Hierbei handelt es sich aber um ein //globales Aggregate// mit allen bekannten Nachteilen:
  * Bei tausenden von Projekten müsste das gesamte Aggregate geladen werden wenn ein neues dazu kommt oder die vorhandene Struktur verändert wird - kostspielig,
  * Bei Hunderten von Anwendern, die allesamt auf die Projektstruktur zugreifen möchten, besteht ein großes Konfliktpotenzial. Das kann zwar aufgelöst werden, indem man bei einem Zugriffskonflikt((gleichzeitiger Zugriff)) die Aktion ein weiteres mal sendet. Eine saubere Trennung wäre das trotzdem nicht, sondern nur eine nachgelagerte Lösung eines Problems, das durch die schlechte Wahl der Aggregates entstanden ist.
==== Das Hauptprojekt als Aggregate Root ====
Man könnte das Hauptprojekt, bzw. den //Projektstrukturplan//((der dann im Grunde vom Hauptprojekt identifiziert wird)) als Aggregate Root verwenden:
{{ :applications:prom:mainprojectaggregates.png?nolink |}}
So können alle Regeln sicher gestellt werden, u.a.
  * keine Zirkelbezüge
  * keine Vermischung von Projekten und Projektvorgängen auf einer Ebene
  * Statuskombinationen von Projekt zu Teilprojekt
  * und vieles mehr
Es gibt trotzdem noch Problemen mit dieser Struktur, ähnlich wie bei einem globalen Aggregate:
  * Immer noch ein Konfliktpotenzial, weil der Zugriff auf alle Teilelemente immer über das Hauptprojekt läuft. Angenommen ein Organisationsleiter legt ein Hauptprojekt an und darunter 3 Teilprojekte, die er alle an Teilprojektleiter delegiert. Die drei Teilprojektleiter sollten nun unabhängig von einander an ihren Teilprojekten arbeiten können, ohne sich in die Quere zu kommen. Das ist in dieser Struktur nicht möglich, bzw. nur mit hohen Kosten verbunden. Wenn z.B. ein Teil-Teilprojektleiter an Projekt 1.2.2 //arbeitet//((Änderungen vornimmt)), müsste immer die Gesamte Struktur geladen werden. Und wenn ein anderer an Projekt 1.2.1 arbeitet, müssten die Änderungen bei Konflikten eventuell mehrmals gesendet werden, damit sie gespeichert werden können.
  * Es gibt keine Möglichkeit aus einem Teilprojekt((Entität)) ein Hauptprojekt((Aggregate Root)) zu machen - Man kann keine Entitäten aus Aggregates ziehen um daraus eigene Aggregates zu machen.
  * Es gibt keine Möglichkeit aus einem Hauptprojekt ein Teilprojekt zu machen((Die Möglichkeit gibt es schon, indem man eine Verteilte Transaktion startet, ein neues Teilprojekt anlegt, alles aus dem Hauptprojekt kopiert, und dann das Hauptprojekt löscht. //Alles// kopieren kann aber viele abhängige Daten bedeuten, auch bereits erfasste und fakturierte Zeitdaten. Also keine Aktion, die man in dieser Struktur ohne weiteres anbieten sollte)).
Ein Problem ist, dass die Projektstruktur Projekte enthält. Im Grunde müsste die Projektstruktur Referenzen auf Projekt enthalten, wobei jedes Projekt ein eigenes Aggregate ist:
==== Projektstruktur als Aggregate Root ====
{{ :applications:prom:projectstructureaggregateroots.png?nolink |}}
Das sieht ja schon gewaltig aus. Ist aber im Grunde recht einfach. Ein Projekt ist ein eigenständiges Aggregate, und kann auch als solches //existieren//. Über die Projektstrukturpläne wird es in eine Struktur eingefügt.
\\ \\
Innerhalb einer Projektstruktur können Regeln bezüglich der Zirkelbezüge und dem Vermischen von Projekten und Projektvorgängen geprüft und eingehalten werden. Das Arbeiten am Projekt ist unabhängig vom Arbeiten an der Struktur, was schon ein großer Schritt in die richtige Richtung ist.
\\ \\
Was noch nicht geht ist, dass die Teilprojektleiter unabhängig von einander die Strukturen bestimmen können. Ein weiters Problem entsteht, wenn man z.B. die Referenz auf Projekt 1.2 aus der Projektstruktur 1 in die Projektstruktur 2 unter die Referenz auf Projekt 2 hängen möchte((Wenn man also Projekte von einer Struktur in eine andere verschieben kann. Wenn das nicht möglich sein soll, trifft das folgende nicht zu)). Man müsste alle Referenzen unter der Referenz auf Projekt 1.2 ebenfalls mit rüber nehmen, also die Referenzen auf die Projekte 1.2.1 und 1.2.2. Es gäbe also 6 Schritte:
  - Löse die Referenz von Projekt 1.2.1 auf die Referenze auf Projekt 1.2 in der Struktur 1 auf
  - Löse die Referenz von Projekt 1.2.2 auf die Referenze auf Projekt 1.2 in der Struktur 1 auf
  - Löse die Referenz von Projekt 1.2 auf die Referenz auf Projekt 1 in der Struktur 1 auf
  - Erstelle eine neue Referenz unter der Referenz auf Projekt 2 in der Struktur 2 auf Projekt 1.2
  - Erstelle eine neue Referenz unter der Referenz auf Projekt 1.2 in der Struktur 2 auf Projekt 1.2.1
  - Erstelle eine neue Referenz unter der Referenz auf Projekt 1.2 in der Struktur 2 auf Projekt 1.2.2
Es sind 6 Schritte, die 2 Aggregates betreffen. Die Reihenfolge muss eingehalten werden, weil die Struktur nach jedem Schritt konsistent sein muss. Man könnte die Schritte 1 bis 3 und 4 bis 6 verschmelzen. Es bleiben aber immer auf jeden Fall 2 Schritte.
\\ \\
Das bedeutet auch, dass die globale Sicht nicht immer zwingend konsistent sein muss. Wenn man das Ergebnis der Schritte 4 bis 6 vor dem Ergebnis der Schritte 1 bis 3 sieht((Auch wenn alles in einer UoW passiert, betreffen die Schritte 2 unterschiedliche Aggregates, und die Reihenfolge in der diese beobachtet werden, ist nicht immer sicher gestellt)), würde man Projekt 1.2 mit den Teilprojekten 1.2.1 und 1.2.2 in beiden Projektstrukturen sehen. Das wäre nur vorübergehend, und man würde Mechanismen einbauen, um die Mengen-basierte Regel schließlich konsistent einzuhalten((z.B. eine UoW, oder kompensierende Aktionen)).
\\ \\
Genauso wichtig, wenn nicht wichtiger, ist es, dass die Komponenten, die das Lesemodell verwenden, von dieser möglichen, vorübergehenden Inkonsistenz wissen und sie nicht als Fehler sehen, sondern Wege haben, damit umzugehen. Es gibt aber auch noch folgende Möglichkeit:
==== Projekt plus Teilprojekt als Aggregate ====
{{ :applications:prom:projectwithsubprojectsaggregate.png?nolink |}}
Was hat das denn wieder auf sich? Es gibt in diesem Modell keine separaten Projektstrukturen, die vorhanden Projekte in eine Baumstruktur bringen. Die Struktur ist Teil des Projektes. Das ist im Grunde eine sehr natürliche Herangehensweise. Ein Organisationsleiter kann ein Hauptprojekt anlegen, es auf mehrere Teilprojekte unterteilen, und diese abgeben. Er bestimmt die Teilprojektstruktur unter dem Hauptprojekt. Das Teilprojekt kann dann aber komplett an jemanden anderes abgegeben werden((oder es bleibt (zusätzlich) unter seiner Kontrolle)).
\\ \\
Die Teilprojekte sind völlig unabhängig von einander. Ein Projekt kümmert sich selbst um die Regel, dass man Projekte und Projektvorgänge((oder Projekte, Produkte, Arbeitspakete, Aufgaben - aus der Projektstrukturplanung)) nicht auf einer Ebene mischen darf.
\\ \\
Wenn man nichts ändern darf, ist eine Baumstruktur ohne Zirkel sicher gestellt. Wie ein Baum wächst die Struktur, beginnend mit einem Hauptprojekt, aus dem Teilprojekte entwachsen. Aus jedem Teilprojekt können wieder neue Äste wachsen, usw.
=== Schwachpunkte ===
  * Anlage eines Teilprojektes betrifft 2 Aggregates. Im Projekt wird eine Referenz auf das Teilprojekt hinzugefügt, das Teilprojekt selbst muss dazu angelegt werden. Ohne UoW((Unit of Work)) könnte es passieren, dass nur einer der beiden Schritte erfolgreich ausgeführt wird. Was passiert mit einer Referenz auf ein Teilprojekt das nicht da ist? Wie wird dafür kompensiert? Wird die Referenz voreilig gelöscht, kann es sein, dass das Teilprojekt angelegt wird, aber ohne übergeordnetes Projekt. Wird sie zu spät gelöscht, glaubt das Projekt ein Teilprojekt zu haben und lässt z.B. eine Anlage von Projektvorgängen nicht zu.
=== Vergleich zu dem umgedrehten Modell ===
Das //umgedrehte// Modell ist eins, in dem ein Projekt nicht seine Teilprojekte kennt, sondern ein Teilprojekt sein übergeordnetes Projekt kennt:
{{ :applications:prom:projectreferencingparentprojectaggregate.png?nolink |}}
Datenbank-technisch baut man so eine Baumstruktur auf. Die Herangehensweise scheint auch recht natürlich: Als Verantwortlicher eines Projektes lege ich ein Teilprojekt an, das //auf mich zeigt//. Ab dann wird es aber unnatürlich. Ich weiß nämlich nichts mehr vom Teilprojekt sobald die Aktion fertig ist. In dem Modell von oben weiß das Teilprojekt nichts vom übergeordneten Projekt - was ist also besser? Gucken wir uns mal eine Regel an:
== Regel: Projekte und Vorgänge dürfen nicht auf einer Ebene vermischt werden ==
Wenn das Teilprojekt sein übergeordnetes Projekt kennt, kann diese Regel nicht strikt eingehalten werden. Vor der Teilprojektanlage wird geprüft, ob das übergeordnete Projekt bereits Projektvorgänge hat. Wenn ja, wird die Anlage abgelehnt, wenn nicht, kann das Teilprojekt angelegt werden. Diese Prüfung läuft aber außerhalb der Transaktion, mit der Möglichkeit, dass das Ergebnis hinfällig ist sobald das Teilprojekt angelegt ist. Man müsste somit den Fall einer Vermischung mit einarbeiten und dafür //kompensieren//.
\\ \\
Wenn ein Projekt seine Teilelemente kennt, und separate Referenzen auf Teilprojekte und auf Projektvorgänge hält, dann kann mit absoluter Sicherheit verhindert werden, dass Teilprojekte und Projektvorgänge auf einer Ebene vermischt werden.
\\ \\
Diesen Vergleich //gewinnt// also die Struktur, in der das Projekt seine Teilprojekte kennt vs. der Struktur in der das Teilprojekt sein übergeordnetes Projekt kennt.
== Regel: Ein Projekt hat kein oder ein übergeordnetes Projekt ==
Das ist ein inhärenter Teil der Definition einer Baumstruktur. 
=== Bidirektionale Referenzen ===
Ein Teilprojekt kennt sein übergeordnetes Projekt, und ein Projekt kennt seine Teilprojekte:
{{ :applications:prom:bidirectionalprojectreferences.png?nolink |}}
Wie kann das funktionieren? Ist da nicht unendlich viel Potenzial für Konflikte? Gehen wir mal die einzelnen Fälle durch:
== Teilprojektanlage ==
Eine Teilprojektanlage betrifft immer 2 Aggregates. Es wird ein neues Projekt hinzugefügt, welches auf das übergeordnete Projekt zeigt, und dem übergeordneten Projekt wird das neue Teilprojekt hinzugefügt. Man muss in diesem Fall nur die Reihenfolge einhalten, erst das Teilprojekt anzulegen, dann das Teilprojekt der Liste der Teilprojekte des übergeordneten Projektes hinzuzufügen. Der zweite Schritt darf erst angefordert werden, nachdem der erste erfolgreich durchgeführt wurde. Das //Read Model// benötigt immer beide Schritte, um das neue Teilprojekt als solches zu akzeptieren. Nur wenn die Ereignisse beider Schritte beobachtet/erhalten wurden, wird das neue Teilprojekt angezeigt. Ein Projekt mit Referenz zu einem übergeordneten Projekt, das aber nicht in der Liste der Teilprojekte dieses Projektes enthalten ist, existiert im Grunde nicht.
== Teilprojekt umhängen ==
Das ist schwieriger, und hierfür muss ein Prozess herhalten. Wenn man bedenkt, dass das //Read Modell// ein Teilprojekt einem übergeordneten Projekt immer nur zuordnet, wenn es von beiden Projekten die Information erhält, dass die Zusammenführung passiert ist, wäre folgender Prozess denkbar, wenn Teilprojekt 1.1 von Projekt 1 unter Projekt 2 gehängt werden soll:
  - Teilprojekt 1.1 wird der Teilprojektliste von Projekt 2 zugeordnet. Das hat zur Folge, dass Projekt 2 nun von der Zugehörigkeit eines Teilprojektes ausgeht, und seine Regeln sicher stellen kann. Für alle außenstehenden hängt Teilprojekt 1.1 aber noch ausschließlich unter Projekt 1,
  - In Teilprojekt 1.1 wird Projekt 2 als übergeordnetes Projekt gesetzt. Das hat zur Folge, dass Projekt 2 nun auch im //Read Model// unter Projekt 2 hängt, und das ausschließlich, weil es zwar in der Teilprojektliste von Projekt 1 hängt, aber nicht auf Projekt 1 zeigt,
  - Teilprojekt 1.1 wird aus der Teilprojektliste von Projekt 1 entfernt.
Diese Schritte, in dieser Reihenfolge, sind notwendig und ausreichend. Im Lesemodell wird Teilprojekt 1.1 immer unter höchstens((Wenn die beobachtete Reihenfolge eine andere ist als die veröffentlichte, kann es sein, dass z.B. Schritt 3 vor Schritt 2 beobachtet wird)) einem Projekt hängen. Es wird niemals verloren gehen, was z.B. der Fall wäre, wenn es erst aus der Teilprojektliste von Projekt 1 entfernt würde, und der Prozess dann hängen bleibt.
\\ \\
Wenn nun Schritt 1 erfolgreich durchgelaufen ist, Schritt 2 aber abgelehnt wird, würde die Saga kompensieren, indem sie das Teilprojekt wieder aus der Teilprojektliste von Projekt 2 entfernt. Dann ist alles beim Alten. Wenn Schritte 1 und 2 durchlaufen, Schritt 3 aber fehlschlägt, gibt es einen Zustand, der aufzulösen ist. Es sollte keinen Grund geben, dass der letzte Schritt fehlgeschlagen ist, da man vor dem ersten Schritt bereits geprüft haben sollte, ob Projekt 1 ein Entfernen von Teilprojekt 1.1 erlaubt. Im besten Falle merkt man nichts davon, da das Lesemodell Projekt 1.1 nicht mehr in den Teilprojekten von Projekt 1 anzeigt.
\\ \\
Im schlimmsten Fall kann man Projekt 1 aber keinen Vorgang hinzufügen, weil es denkt, dass es noch ein Teilprojekt besitzt. Hier liegt aber die Krux von //kompensierenden Aktionen//. Es gibt keine transaktionale Sicherheit. Angenommen, Teilprojekt 1.1 wird gleichzeitig unter Projekt 3 gehängt, und folgendes passiert:
  - Teilprojekt 1.1 wird der Liste der Teilprojekte von Projekt 2 hinzugefügt
  - Teilprojekt 1.1 wird der Liste der Teilprojekte von Projekt 3 hinzugefügt
  - In Teilprojekt 1.1 wird Projekt 2 als übergeordnetes Projekt gesetzt
  - In Teilprojekt 1.1 wird Projekt 3 als übergeordnetes Projekt gesetzt
  - Teilprojekt 1.1 wird aus der Teilprojektliste von Projekt 1 entfernt
  - Teilprojekt 1.1 wird aus der Teilprojektliste von Projekt 1 entfernt
Jetzt hängt Teilprojekt 1.1 unter Projekt 3, weil sie sich gegenseitig referenzieren. Teilprojekt 1.1 ist aber auch in der Liste der Teilprojekte von Projekt 2. Kann man es dort einfach wieder löschen? Das ist //gefährlich//, denn angenommen es handelt sich um den ersten Fall, in dem das Teilprojekt unter Projekt 2 gehängt wird((ohne, dass es gleichzeitig unter Projekt 3 gehängt wird)), und es ist gerade der erste Schritt durchlaufen worden, die nächsten beiden stehen noch an. Wenn man nun Teilprojekt 1.1 händisch aus der Teilprojektliste von Projekt 2 löscht((weil man denkt, dass man kompensiert)), würde der Prozess in den nächsten beiden Schritten Projekt 2 als übergeordnetes Projekt von Teilprojekt 1.1 setzen und Teilprojekt 1.1 aus der Teilprojektliste von Projekt 1 entfernen. Das Ergebnis wäre, dass Teilprojekt 1.1 zwar Projekt 2 referenziert, aber in keinem der beiden Projekte((1 und 2)) in der Liste der Teilprojekte enthalten ist.
\\ \\
Der Prozess des Umhängens muss also erweitert werden, damit er keinen inkonsistenten Zustand hinterlässt. Und zwar am besten so, dass keine verteilte Transaktion notwendig wird, und auch keine Reservierungen. Erstens wird es die Möglichkeit geben, ein Teilprojekt einem Projekt als //schwebend// hinzuzufügen. Das verbessert die Teilprojektanlage:
== Teilprojektanlage, Version 2 ==
In dieser Version wird dem übergeordneten Projekt als erstes ein //schwebendes// Teilprojekt hinzugefügt. Dadurch weiß man, dass das Teilprojekt vom Projekt akzeptiert wird, und das Projekt kann sich auf ein Teilprojekt vorbereiten. Jetzt wird das neue Teilprojekt hinzugefügt, welches auf das übergeordnete Projekt zeigt - und zwar in dem Wissen, dass das übergeordnete Projekt es akzeptieren wird, und es nicht u.U. brach rumliegen wird. Danach wird dem übergeordneten Projekt mitgeteilt, dass aus dem //schwebenden// Teilprojekt ein echtes werden kann. Es ist im Lesemodell aber bereits als schwebendes Teilprojekt sichtbar - der Grund liegt im Umhängen.
\\ \\
Es wird für ein sicheres Umhängen zudem im Projekt möglich sein, ein Teilprojekt zum Löschen vorzumerken:
== Teilprojekt umhängen, Version Zwei ==
Teilprojekt 1.1 wird mit folgendem Prozess von Projekt 1 unter Projekt 2 gehängt:
  - Teilprojekt 1.1 wird in der Teilprojektliste von Projekt 1 zum Löschen((bzw. Umhängen)) vorgemerkt. Dadurch passiert noch gar nichts, das Teilprojekt bleibt Teil von Projekt 1. Zwei wichtige Dinge werden jedoch vorbereitet. Erstens wird der letzte Schritt mit Sicherheit funktionieren, d.h. das Löschen eines zum Löschen vorgemerkten Teilprojektes wird auf jeden Fall funktionieren. Das Projekt wird dafür sorgen, z.B. indem der Status nicht verändert werden kann solange es zum Löschen vorgemerkte Teilprojekte gibt. Zweitens wird niemand anderes das Teilprojekt zum Löschen vormerken können. Das Problem, dass ein Teilprojekt gleichzeitig umgehängt wird, wird somit verhindert.
  - Teilprojekt 1.1 wird in der Teilprojektliste von Projekt 2 //schwebend// hinzugefügt. Wenn Projekt 2 das akzeptiert, garantiert es, dass es Teilprojekt 1.1 aufnehmen wird, und auch, dass es ohne Fehler wieder gelöscht werden kann wenn einer der folgenden Schritte fehlschlägt,
  - In Teilprojekt 1.1 wird Projekt 2 als übergeordnetes Projekt gesetzt. Das hat zur Folge, dass Projekt 2 nun im //Read Model// unter Projekt 2 hängt, und das ausschließlich, weil es zwar in der Teilprojektliste von Projekt 1 hängt((zum Löschen gekennzeichnet)), aber nicht mehr auf Projekt 1 zeigt,
  - Teilprojekt 1.1 wird der Teilprojektliste von Projekt 2 nun fest zugeordnet. Das kann nun nach den ersten 3 Schritten gemacht werden, weil der Prozess jetzt weiß, dass alles funktioniert hat und alle Vormerkungen auflösen kann,
  - Teilprojekt 1.1 wird aus der Teilprojektliste von Projekt 1 entfernt.
Schritte 1 und 2 garantieren, dass Schritte 4 und 5 funktionieren, bzw. können Schritte 1 und 2 garantiert rückgängig gemacht werden, wenn Schritt 3 fehlschlägt. Schritt 3 muss selbst nicht mit einer //Vormerkung// durchgeführt werden, weil alle folgenden Schritte durch die vorhergehenden garantiert funktionieren werden.
\\ \\
Der gesamte Prozess wird von den Schritten 1 und 5 ummantelt, d.h. dass man Teilprojekt 1.1 nicht mehrmals gleichzeitig umhängen kann - der Prozess wird vom übergeordneten Projekt geschützt. Wenn ein Umhängen also nur über diesen Prozess laufen kann, wird Teilprojekt 1.1 immer maximal unter einem Projekt hängen, und immer schließlich unter genau einem übergeordneten Projekt.
== Ein Projekt zum Hauptprojekt machen ==
Dieser Prozess läuft genau so ab wie der Prozess des Umhängens, nur dass es die Schritte 2 und 4 nicht gibt.
== Ein Hauptprojekt zum Teilprojekt machen ==
Hierfür reicht der Prozess noch nicht aus. Wenn man Projekt 1 gleichzeitig unter Projekt 2 und unter Projekt 3 hängt, und dafür die Schritte 1, 3 und 5 des Prozesses umsetzt, würden die Schritte alle erfolgreich durchlaufen, und entweder Projekt 2 oder Projekt 3 hätten Projekt 1 in der Teilprojektliste, ohne dass es zurück auf das Projekt zeigt. Somit muss der gesamte Prozess durch ein Vormerken im Teilprojekt geschützt werden, dass es umgehängt werden soll. Damit das auch unter allen Umständen mit ein hundert prozentiger Sicherheit funktioniert, müssen alle Aktionen darüber geschützt werden. Also sieht es letztendlich so aus:
== Teilprojektanlage, finale Version ==
In dieser Version wird dem übergeordneten Projekt als erstes ein //schwebendes// Teilprojekt hinzugefügt((der erste Schritt muss nicht die Teilprojektanlage sein)). Dadurch weiß man, dass das Teilprojekt vom Projekt akzeptiert wird, und das Projekt kann sich auf ein Teilprojekt vorbereiten. Jetzt wird das neue Teilprojekt hinzugefügt, welches //unter Vorbehalt// auf das übergeordnete Projekt zeigt - und zwar in dem Wissen, dass das übergeordnete Projekt es akzeptieren wird, und es nicht u.U. brach rumliegen wird. Danach wird dem übergeordneten Projekt mitgeteilt, dass aus dem //schwebenden// Teilprojekt ein echtes werden kann. Es ist im Lesemodell noch nicht als Teilprojekt des Projektes sichtbar. Das wird es erst nach dem letzten Schritt, in dem es fest auf das übergeordnete Projekt zeigt.
== Teilprojekt umhängen, finale Version ==
Teilprojekt 1.1 wird mit folgendem Prozess von Projekt 1 unter Projekt 2 gehängt:
  - Projekt 2 wird in Teilprojekt 1.1 //unter Vorbehalt// als übergeordnetes Projekt gesetzt. Das Teilprojekt merkt sich Projekt 1 als übergeordnetes Projekt, auf das im Fall der Fälle zurück gebogen werden kann. Projekt 2 wird hierdurch vor einem gleichzeitigen Umhängen in ein anderes Projekt geschützt,
  - Teilprojekt 1.1 wird in der Teilprojektliste von Projekt 1 zum Löschen((bzw. Umhängen)) vorgemerkt. Dadurch passiert noch gar nichts, das Teilprojekt bleibt Teil von Projekt 1. Zwei wichtige Dinge werden jedoch vorbereitet. Erstens wird der letzte Schritt mit Sicherheit funktionieren, d.h. das Löschen eines zum Löschen vorgemerkten Teilprojektes wird auf jeden Fall funktionieren. Das Projekt wird dafür sorgen, z.B. indem der Status nicht verändert werden kann solange es zum Löschen vorgemerkte Teilprojekte gibt. Zweitens wird niemand anderes das Teilprojekt zum Löschen vormerken können. Das Problem, dass ein Teilprojekt gleichzeitig umgehängt wird, wird somit verhindert.
  - [Teilprojekt 1.1 wird in der Teilprojektliste von Projekt 2 //schwebend// hinzugefügt. Wenn Projekt 2 das akzeptiert, garantiert es, dass es Teilprojekt 1.1 aufnehmen wird, und auch, dass es ohne Fehler wieder gelöscht werden kann wenn einer der folgenden Schritte fehlschlägt,]
  - Teilprojekt 1.1 wird der Teilprojektliste von Projekt 2 nun fest zugeordnet. Das kann nun nach den ersten 3 Schritten gemacht werden, weil der Prozess jetzt weiß, dass alles funktioniert hat und alle Vormerkungen auflösen kann,
  - Teilprojekt 1.1 wird aus der Teilprojektliste von Projekt 1 entfernt. Es ist jetzt kurzzeitig keinem Projekt zugeordnet. Das geht aber nicht anders, weil das Setzen von Projekt 2 im Teilprojekt 1.1 der letzte Schritt des Prozesses sein muss.
  - In Teilprojekt 1.1 wird Projekt 2 nun fest als übergeordnetes Projekt gesetzt. Das hat zur Folge, dass Projekt 2 nun im //Read Model// unter Projekt 2 hängt, und das ausschließlich, weil es zwar in der Teilprojektliste von Projekt 1 hängt((zum Löschen gekennzeichnet)), aber nicht mehr auf Projekt 1 zeigt,
Der Prozess wird nun durch Teilprojekt 1.1 geschützt, was auch Sinn hat, denn ein gleichzeitiges Umhängen eben dieses Teilprojektes soll ja verhindert werden. Wie man erkennt, handelt es sich beim Umhängen auch um einen //Prozess// und nicht um einen einfachen Befehl an ein Aggregate, weil der Prozess mehrere Aggregates betrifft. Aber:
=== Wozu diesen komplizierten Prozess mit bidirektionalen Beziehungen? ===
Warum setzt man nicht einfach im Teilprojekt das übergeordnete Projekt? Ein Befehl, ganz simpel. Es gibt dafür mehrere Gründe:
  * Wenn man die Regel, dass man Projektstrukturelemente((Projekt, Produkt, Arbeitspaket, Aktion, Vorgang)) nicht vermischen darf, strikt einhalten möchte, muss das übergeordnete Projekt über seine Teilelemente bescheid wissen,
  * Wenn man zudem im Lesemodell sicher stellen möchte, dass ein Projekt maximal ein übergeordnetes Projekt hat, muss das Projekt zurück auf das übergeordnete Projekt zeigen, und man muss beide Informationen nutzen. Ein Projekt wird dann nur als Teilprojekt eines anderen angezeigt, wenn es Teil der Teilprojektmenge ist, und wenn es auf dieses Projekt zeigt. Ansonsten könnte es passieren, dass man die Ereignisse der Aggregates in solche einer Reihenfolge erhält, dass das Teilprojekt z.B. gleichzeitig Teilprojekt mehrerer Projekte ist. Dafür müsste man kompensieren. Es gar nicht erst zu ermöglichen macht den Umstand wesentlich einfacher((eine Wiederholung der Ereignisse in einer beliebigen Reihenfolge kann nun dazu führen, dass diverse Änderungen nicht //gesehen werden//. Wenn z.B. Teilprojekt 1.1. 10 mal umgehängt wird, und die Ereignisse von Teilprojekt 1.1 als letztes abgespielt werden, würde nur der letzte Zustand angezeigt werden. Alle anderen nicht, weil die Teilprojektliste aller anderen Projekte zwar Teilprojekt 1.1 enthalten würden, es Teilprojekt 1.1 aber noch gar nicht geben würde. Und die ersten 9 der 10 übergeordneten Projekte in der Historie von Teilprojekt 1.1 würden auch nicht als übergeordnete Projekte erscheinen, weil bei der Wiedergabe der Ereignisse von Teilprojekt 1.1 keines dieser Projekte Teilprojekt 1.1 als Teilprojekt enthalten würde)).
tawiki

User Tools

Site Tools

Page Tools
