Es gab eine lange Suche nach dem richtigen Modell für die Projektstruktur. Das CAP Theorem sagt uns ja, dass man immer nur maximal 2 von 3 gewünschten Zielen erreichen kann: Konsistenz, Verfügbarkeit, Partitionstoleranz. In der Suche nach der optimalen Projektstruktur habe ich mich immer wieder im Kreis¹⁾ gedreht, weil mal die Konsistenz der Schwerpunkt der Analyse war, dann die Partitionstoleranz, dann die Verfügbarkeit.

Hier sind die Regeln, die eingehalten werden müssen, und die zur letztendlichen Struktur geführt haben:

• Die Projektstruktur muss immer konsistent sein. Es darf also in der Baumstruktur keine Zirkelbezüge geben, und ein Projekt darf nicht mehrmals im Baum erscheinen,
• Die Projektnummern müssen global eindeutig sein, und es muss die Möglichkeit geben, sie fortlaufend und lückenlos zu erzeugen,
• Projekte müssen frei verschiebbar sein, innerhalb eines Hauptprojektes, und auch zwischen Hauptprojekten,
• Ein Projektleiter muss Teilprojekte anlegen können und diese komplett an Teilprojektleiter abgeben können,
• Wenn Teilprojektleiter an ihren Projekten arbeiten, soll dieses unabhängig voneinander geschehen, d.h. dass der Projektstrukturplan pro Teilprojekt isoliert von den anderen Projektstrukturplänen verwalten und gestalten werden können muss.

Die ersten 3 Regeln sagen nichts anderes, als dass es eine globale Projektstruktur geben muss. Nur so kann man diese Regeln konsistent einhalten. Da eine Projektanlage aber ein Punkt ist, bei dem die Konsistenz absolut vorrangig ist, wird der Anwender verstehen, wenn es dort eventuell zu Zeitverzögerungen kommen kann²⁾.

Die letzten beiden Punkte besagen, dass Änderungen innerhalb eines Projektes aber nicht global serialisiert werden dürfen. Sobald ein Projekt angelegt wurde, sollten Änderungen maximal innerhalb des Projektes serialisiert werden. Die globale Projektstruktur bestimmt also nur die Position des Projektes im Baum. Jedes Projekt hat dann wiederum eine eigene Projektstruktur für Produkte, Arbeitspakete und Aufgaben|Vorgänge. Die mehrstufige Projektstruktur löst das Problem der gleichzeitigen Zugriffe auf unterschiedliche Teilprojekte. Da die Projekt von der Baumstruktur lediglich referenziert werden³⁾, hängen sie nicht alle gemeinsam im Projektbaum Aggregate und kommen sich nicht in die Quere.

Dass der Projektbaum für eine Neuanlage eines Projektes/Teilprojektes komplett serialisiert werden muss fühlt sich noch unschön an. Was für eine schreckliche Aussage! Wenn aber Konsistenz der Schwerpunkt ist, und zwar sofortige, transaktionale Konsistenz, und keine schließliche Konsistenz, muss das so sein. Was man zumindest optimieren kann, ist nicht immer den gesamten Baum laden zu müssen. Wenn z.B. ein neues Projekt angelegt wird, braucht man den Baum gar nicht zu laden, denn durch ein neues Projekt kann es nicht zu Zirkelbezügen kommen. Man muss nur das Projekt dem Baum hinzufügen. ORM⁴⁾ Tools wie EF⁵⁾ bieten das mit lazy loading an.

Es ist ja nicht in Stein gemeißelt, und vielleicht kann man die globale Projektstruktur später noch aufteilen. Wenn man z.B. die Regel aufheben kann, dass ein Teilprojekt zum Hauptprojekt werden kann, oder ein Hauptprojekt zum Teilprojekt, dann hat man keinen globalen Projektbaum mehr, sondern einzelne Hauptprojektbäume. Wenn die Projekte in solch einem Hauptprojektbaum diesen nicht verlassen können, braucht man kein globales Aggregate, weil die Hauptprojektbäume vollkommen unabhängig voneinander existieren können.

Die Projektneuanlage wird so ablaufen, dass erst ein neues Projekt angelegt wird, und es danach im Baum an der richtigen Stelle eingesetzt wird. Das Lesemodell wird das Projekt erst anzeigen, wenn beide Aktionen erfolgreich ausgeführt wurden. Ein neues Projekt in den Baum zu hängen sollte immer funktionieren, daher sollte es selten dazu kommen, dass Projekte brach rum liegen. Und auch wenn, haben sie noch keine Projektnummer erhalten, und sind sonst auch nirgendwo verwendet worden⁶⁾, stören also nicht weiter.

Ein Projekt wird im Projektbaum umgehängt. Das ist ein Vorgang, der einen Schritt benötigt, somit immer konsistent durchgeführt wird. Wenn es bloß so einfach wäre. Es gibt ja noch die Regel auf einer Ebene dürfen Projekte, Produkte, Teilaufgaben, Arbeitspakete, Aktivitäten und Vorgänge nicht vermischt werden. Das Projekt als logische

Es gibt Projekte mit Teilprojekten⁷⁾. Ein Hauptprojekt ist Teil seiner eigenen Teilprojektliste - ein Projekt muss immer Teil mindestens einer Teilprojektliste sein, zum Schutz der gleichzeitigen Verschiebung des Projektes durch mehrerer User:

1. Lege neues Projekt an,
2. Füge Hauptprojekt als ID-Referenz in der eigenen Projektliste an.

Beide Schritte müssen ausgeführt worden sein, damit das Projekt im Lesemodell erscheint. Zudem wird der zweite Schritt immer nur nach dem ersten ausgeführt werden können, da das Hauptprojekt für den zweiten Schritt ja das Aggregate Root ist.

1. Füge Teilprojekt als schwebende ID-Referenz im übergeordneten Projekt an. Dadurch wird sicher gestellt, dass das übergeordnete Projekt ein Teilprojekt akzeptieren wird, und dass es nichts anderes als ein weiteres Teilprojekt akzeptieren wird. D.h. die Regel der nicht-Vermischung von Elementen unterschiedlicher Art auf einer Eben wird hierdurch geschützt. Zudem garantiert das Projekt, dass es das Teilprojekt akzeptiert, aber auch, dass die schwebende Referenz wieder gelöscht werden kann.
2. Lege neues Projekt an,
3. Mache im übergeordneten Projekt aus schwebender ID-Referenz eine feste.

Wie in der Hauptprojektanlage müssen alle Schritte durchgeführt werden bevor das neue Projekt im Lesemodell erscheint.

1. Markiere ID-Referenz des Projekts im übergeordneten Projekt zum Löschen vormerken. Das übergeordnete Projekt kann das Projekt selbst sein, sollte es sich um ein Hauptprojekt handeln. Dadurch verschwindet das Projekt im übergeordneten Projekt. Es wird auch vom übergeordneten Projekt garantiert, das das Löschen funktionieren wird, und dass die Kennzeichnung rückgängig gemacht werden kann,
2. Füge Projekt als ID-Referenz im der Teilprojektliste des neuen Projektes hinzu - es kann sich dabei auch um das eigene Projekt handeln, wenn es zum Hauptprojekt werden soll. Das muss nicht schwebend geschehen, denn nach diesem Schritt sind die folgenden Schritte garantiert. Dadurch erscheint das Projekt im Lesemodell unter dem neuen Projekt, bzw. als Hauptprojekt,
3. Lösche ID-Referenz aus dem letzten übergeordneten Projekt.

Das Umhängen des Projektes wird durch das übergeordnete Projekt geschützt, d.h. mann wird es nicht gleichzeitig mehrmals verschieben können. Der erste Schritt schlägt fehl, wenn das Projekt bereits von einem anderen Prozess zum Löschen markiert wurde. Daher auch der Umstand, dass ein Hauptprojekt unter sich selbst hängt, denn ansonsten könnte man es nicht schützen. Wie man sieht, hat ein Projekt selbst gar keine Wahl ob es umgehängt wird oder nicht. Man kann in den Prozess einbauen, dass es eine Referenz auf das Hauptprojekt hält, und in Schritt 3 umgehängt wird, nachdem das alte und das neue übergeordnete Projekt ihr Einverständnis erklärt haben.

Davon wird aber abgesehen, denn es wird von einem Top-Down Workflow ausgegangen. Der Verantwortliche des übergeordneten Projektes entscheidet, was mit den Teilprojekten passiert, bzw. wo sie zu liegen haben. Der Verantwortliche des Teilprojektes kümmert sich nur um den Inhalt des Teilprojektes, also um weitere Teilprojekte, Produkte, Teilaufgaben, Arbeitspakete, usw.

Es kann passieren, dass Projekt 1 in der Teilprojektliste von Projekt 2 ist, und umgekehrt. Was wären die Ereignisse?

1. Projekt 1: Lege Projekt 1 an
2. Projekt 1: Hänge Projekt 1 unter Projekt 1 (Hauptprojekt)
3. Projekt 2: Lege Projekt 2 an
4. Projekt 1: Hänge Projekt 2 unter Projekt 1
5. Projekt 2: Hänge Projekt 1 unter Projekt 2

Schritt 4 kann sogar vor Schritt 3 passieren, bzw. vom Lesemodell beobachtet werden. Es würde 2 Tabellen im Lesemodell geben. Einmal die Tabelle mit den Projektdetails, dann die Tabelle mit der Projektstruktur:

Wie sehen die Tabellen nach den einzelnen Schritten aus?