tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== PRO•M Terminplanungskontext ======
Die Terminplanung ist ein Customer Kontext von PRO•M Legacy. PRO•M Legacy ist dabei ein [[http://en.wikipedia.org/wiki/Big_ball_of_mud|big ball of mud]] und beinhaltet, bzw. umfasst diverse Kontexte.
{{ :prom20:scheduling:downstreamcontext.png?nolink |}}
===== Customer Bounded Context =====
Die Terminplanung ist insofern ein Kunde von PRO•M Legacy, dass es das //Ergebnis// der Aktionen in den anderen Kontexten kennt. Da die vorhandenen Module in Delphi 6 mit Midas entwickelt sind, und keine Ereignisse auslösen die die Terminplanung für den Aufbau von eigenen Sichten verwenden kann, werden die Ergebnisse direkt in Form von Sichten((SQL Views)) verwendet.
\\ \\
Die Terminplanung arbeitet z.B. mit Mitarbeitern. Sie hat keine Regeln die Mitarbeiter betreffend, arbeitet also lediglich mit den Identifikatoren der Mitarbeiter((den IDs)). D.h. dass es der Terminplanung für die Einhaltung der eigenen Regeln ausreicht, dass sie weiß, dass ein Termin für einen Mitarbeiter, der durch die ID 27 identifiziert wird.
\\ \\
Die Terminplanung kennt aber Begriffe wie //Personalnummer// und //Name// eines Mitarbeiters. Sie weiß aber ebenso, dass diese Eigenschaften eines Mitarbeiters im //PRO•M Employment// Kontext, bzw. im //PRO•M Address// Kontext gehalten und verwaltet werden. Wozu also die Verwaltung nochmal selbst bauen, wenn man doch einfach als Kunde dieser Kontexte auf die Ergebnisse zugreifen kann((Auch hier scheint mein Verständnis von dem vieler anderer CQRS Jüngern abzuweichen. Ich glaube, die meisten zielen auf //Separate Ways// in den //Bounded Contexts// und duplizieren lieber alles, als die Kontexte zu verknüpfen. Ich finde, das widerspricht dem DRY Prinzip, und auch, dass das viel zu aufwendig ist. Soll ich in der Teminplanung die komplette Projektstruktur samt Verwaltung duplizieren? Völliger Schwachsinn.))?
==== Implementierung ====
=== Ereignis gesteuert ===
Wenn ich als Kunde eines liefernden Kontextes die veröffentlichten Ereignisse des Lieferanten abgreifen kann, kann ich mir meine eigene Sicht auf die vom Lieferanten Kontext benötigten Eigenschaften aufbauen. Die Sicht wäre zwar nur schließlich konsistent, aber das ist bei übergreifenden Kontexten meiner Meinung nach überhaupt kein Problem((Innerhalb eines Kontextes möchte ich transaktionale Konsistenz haben - aber das bin dann nur ich, und ein paar andere vorsichtige Menschen.)).
=== Pull ===
Wenn der liefernde Kontext keine Ereignisse veröffentlicht, müsste ich mir die mir wichtigen Daten vom Kontext holen. Wenn die Kontexte nicht zusammen liegen, mache ich das durch regelmäßige Abfragen((Pull)) der Sichten des Lieferanten, bzw. frage ich ihn immer zeitnah ab, wenn ich selbst Daten liefern muss.
\\ \\
Wenn die Sichten der Kontexte im selben Datenbankserver liegen, kann die zeitnahe Abfrage so aussehen, dass die Sichten des liefernden Kontextes einfach in die Sichten des Kundenkontextes eingebunden werden - abstrahiert durch eine Sicht des Kundenkontextes((Eine Sicht ViewAddress im PRO•M Address Kontext mit dem Namen eines Mitarbeiters würde eine entsprechende Sicht ViewAddress im PRO•M Terminplanungs Kontext erhalten. Diese macht einfach ein SELECT * FROM PromAddress.Query.ViewAddress. Sie kann aber jederzeit durch SELECT * FROM PromScheduling.Query.Address abgelöst werden, wo Address eine Tabelle ist, die durch Pollen oder Pushen des Adress Kontextes aufgebaut wird)). Jedenfalls werde ich das so machen.
tawiki

User Tools

Site Tools

Page Tools
