tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Aggregate Design ======
===== Beispiel Projektstruktur =====
{{ :technology:domainmodel:projectstructuresummary.png?nolink |}}
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 darf((weil das wenig Sinn hat)). Abhängig der Regel, müssen unterschiedlich viele andere Projekte betrachtet werden, um die Regel einzuhalten.
  - Es gibt Regeln, für deren Einhaltung man die gesamte Projektstruktur benötigt:
    * Ein Projekt darf nur einmal in der Struktur hängen((wenn die Struktur ein Projekt lediglich referenziert))
    * Die Projektnummer muss eindeutig sein
  - Es gibt Regeln, für deren Einhaltung man die Struktur innerhalb eines Hauptknoten braucht,
  - Es gibt Regeln, für die man nach unten gucken muss,
  - Es gibt Regeln, für die man nach oben gucken muss.
Das Problem bei dieser Betrachtung ist, dass man die Projektstruktur strukturell angeht((was der Name ja im Grunde andeutet)). Ein Domänenmodell soll aber das gewünschte Verhalten der Domäne bedienen. Was soll die Projektstruktur hergeben?
==== Verhaltenssicht ====
  - Ich möchte ein neues Hauptprojekt anlegen können,
  - Ich möchte ein neues Teilprojekt zum Hauptprojekt anlegen können,
  - Die Projektnummer soll automatisch vergeben werden, wenn ich das Projekt anlege oder freigebe,
  - Die Projektnummernvergabe soll das darüber liegende Projekt mit einbeziehen,
  - Die Projektnummer soll global eindeutig sein,
  - 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,
  - Aus einem Teilprojekt soll ein Hauptprojekt werden können,
  - Ein Hauptprojekt soll zum Teilprojekt eines anderen Projektes werden können,
  - Ebenso ein Teilprojekt
Gehen wir die Punkte mal einzeln durch
  - dfas

==== Globales Aggregate für die Projektstruktur ====
Die Projektstruktur sieht beispielhaft aus wie folgt:
\\ \\
{{:technology:domainmodel:projectstructureglobalaggregate.png?nolink |}}
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 ist((Connection.Commit)).
\\ \\
Möchte man eine global konsistente Sicht auf die Baumstruktur, dann muss die Baumstruktur auch global gesichert werden, d.h. ein universelles Aggregate werden((pro Mandant)). 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:
\\ \\
{{:technology:domainmodel:projectstructureaggregatepermainproject.png?nolink |}}
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 wurde((nicht vergessen, jedes Aggregate hat eine eigene, isolierte Sicht auf das Geschehene)). 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 leben((und nicht einmal nach der Möglichkeit gefragt haben, ein Projekt unter ein anderes Hauptprojekt zu hängen)).
\\ \\
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
tawiki

User Tools

Site Tools

Page Tools
