Differences

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

--- technology:domainmodel:aggregatedesign [2013/03/06 12:47]
rtavassoli
+++ technology:domainmodel:aggregatedesign [2013/03/06 14:27] (current)
rtavassoli [Regeln]
@@ Line 39: / Line 39: @@
 \\ \\
 Die Regeln hängen also auch davon ab, wie das System verwendet werden soll! Ist es ein führendes System? Dann kann man die Auftragsnummer automatisch vergeben und sie darf nicht mehr verändert werden. Ist es nicht das führende System, dann muss die Auftragsnummer frei vergeben werden dürfen, verändert werden dürfen, usw. Soll das somit auch noch pro Kunden konfigurierbar sein?
+=== Prozesse, Prozesse, Prozesse ===
+Es gibt mehrere Möglichkeiten der Umsetzung. Angenommen, der Auftrag gilt mit der ersten Lieferschein Erstellung als unveränderbar. Der Lieferschein darf ebenso nicht mehr verändert werden sobald eine Rechnung für ihn geschrieben wurde.
+\\ \\
+Oder man dreht das Ganze um und erlaubt einen Lieferschein nur für einen freigegebenen Auftrag, und eine Rechnung für einen freigegebenen Lieferschein, in dem Wissen, dass eine Freigabe gleichbedeutend ist mit einer Unveränderlichkeit des Auftrags, bzw. des Lieferscheins.
+\\ \\
+Man muss aber die Möglichkeit der Korrektur vorhalten. Das fällt dann unter Change-Management((Man-agement, also das //Altern des Mannes//. Ist das die Aufgabe eines //man-agers//, seine angestellten so zu quälen, dass sie altern?)). Man könnte also auch genauso erlauben, dass ein Auftrag jederzeit verändert werden darf, ganz egal ob ein Lieferschein bereits erstellt wurde oder nicht. In dem Fall würde u.U. ein Prozess anspringen, der den Lieferschein korrigiert, bzw. einen korrigierten Lieferschein raus schickt. Und das würde wiederum einen Prozess anstoßen, der eine Gutschrift und eine neue Rechnung an den Kunden schickt.
+\\ \\
+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 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