Differences

This shows you the differences between two versions of the page.

--- technology:domainmodel:aggregatedesign [2013/03/06 13:09]
rtavassoli [Regeln]
+++ technology:domainmodel:aggregatedesign [2013/03/06 14:27] (current)
rtavassoli [Regeln]
@@ Line 48: / Line 48: @@
 Und genau diese Prozesse sind es, welche die Domäne interessant machen. Die Objekte((Auftrag, Lieferschein, Rechnung)) sind locker mit einander verknüpft, aber vernünftige Prozesse stellen sicher, dass das System schließlich konsistent ist, d.h. dass letztendlich alles wieder zusammen passt, auch wenn nachträglich was verändert wird.
 \\ \\
-Ich bin aber eher ein Fan davon, es nicht ''top-down'' sondern ''bottom-up'' zu lösen. Damit der Auftrag verändert werden kann, muss vorher der Lieferschein korrigiert werden. Und damit das möglich ist, muss erst die Rechnung gut geschrieben werden. Also nicht einfach den Auftrag ändern lassen und dann nachträglich Dinge korrigieren müssen, sondern vorher die Dinge so einrichten, dass man den Auftrag sorglos ändern kann. Das ist (fast) genauso flexibel, der Anwender ist dadurch aber vorher gezwungen sich Gedanken über die Änderungen zu machen, und nicht nachträglich, wenn er den von ihm verursachten Schlamassel wieder aufräumen muss.
+Ich bin aber eher ein Fan davon, es nicht ''top-down'' sondern ''bottom-up'' zu lösen. Damit der Auftrag verändert werden kann, muss vorher der Lieferschein korrigiert werden. Und damit das möglich ist, muss erst die Rechnung gut geschrieben werden. Also nicht einfach den Auftrag ändern lassen und dann nachträglich Dinge korrigieren müssen, sondern vorher die Dinge so einrichten, dass man den Auftrag sorglos ändern kann. Das ist genauso flexibel, der Anwender ist dadurch aber vorher gezwungen sich Gedanken über die Änderungen zu machen, und nicht nachträglich, wenn er den von ihm verursachten Schlamassel wieder aufräumen muss.
+\\ \\
+Die Schwierigkeit mit meinen Ansatz ist nur, dass die Objekte nicht mehr locker mit einander verknüpft sind, sondern sondern stark. Auftrag, Lieferschein und Rechnung gehören zusammen und haben gemeinsame Regeln. Im Dienstleistungsbereich genauso das Projekt, der Zeitdatensatz, der Wochenbericht((gibt es nicht mehr)), und die Rechnung.
+\\ \\
+Der ''top-down'' Ansatz ist reaktiv, und erlaubt ein offeneres Entitätsmodell. Wie immer hängt es davon ab, was gefordert ist, welchen Ansatz man letztendlich wählt.
+\\ \\
+Was aber schön ist, ist ein Standard den man in den meisten Fällen anwenden kann ohne sich großartig Gedanken machen zu müssen. Am besten ein Standard der die am restriktivste Möglichkeit darstellt, also für alles funktioniert. Nur wenn die Umsetzung zu restriktiv ist kann man Fallweise nach anderen Lösungen suchen. Solch ein Standard wäre z.B. das [[technology:reservationpattern|Reservation Pattern]].
 ===== Beispiel Projektstruktur =====
 {{ :technology:domainmodel:projectstructuresummary.png?nolink |}}

tawiki

User Tools

Site Tools

Differences

Page Tools