tawiki

Hierbei handelt es sich um die Person selbst¹⁾, welche eine echte Person repräsentiert. Die Daten von Person werden absichtlich flach gehalten, damit die Person nicht zu spezifisch wird, und in allen Anwendungen²⁾ verwendet werden kann, wo eine (erweiterbare) Person benötigt wird.

Eine Person wird durch die Kontinuität identifiziert. Sie hat einen Namen und einen Matchcode³⁾, sowie ein Geburtsdatum. Das kann sich alles ändern. Der Name z.B. durch eine Heirat, das Geburtsdatum durch eine Korrektur. Es muss auch alles änderbar sein.

Wenn jemand Hans Hansen, geboren am 1.1.1950 in Petra Petersen, geboren am 31.12.1999 ändert, dann ist das zwar erlaubt und hat wenig Sinn, PRO·M kann das aber nicht verhindern. Der Anwender muss da einfach wissen, was er tut, und die Kontinuität⁴⁾ der Änderungen der Person ist ja vorhanden, so dass im schlimmsten Fall alles wieder korrigiert werden muss.

Es gäbe die Möglichkeit, den Matchcode nach einer Freigabe der Person nicht mehr ändern zu können, oder zumindest den Vornamen, den Mittelnamen, den Geburtsnamen und das Geburtsdatum. Ich denke, so was wäre realisierbar, wenn man dafür einen Freigabeprozess einrichtet, damit mindestens 2 Anwender die Angaben vorher prüfen. Das kann noch weiter analysiert werden.

Es gibt einen Matchcode-Index, über den sicher gestellt wird, dass der Matchcode einer Person pro Mandant eindeutig ist, da über diesen gesucht und über Auswahllisten ausgewählt wird. Ein Index bedeutet immer, dass die Datenbank an dieser Stelle nicht aufteilbar ist, dass also alle Personen im selben transaktionalen Knoten existieren müssen⁵⁾.

Der Matchcode muss aber nicht eindeutig sein, das ist lediglich aus Gründen der Bequemlichkeit so. Eindeutigkeit über Eventual Consistency herzustellen, und dabei auch mal doppelte Matchcodes zuzulassen, wäre absolut kein Problem. Ich sehe bei PRO·M aber keine Notwendigkeit, die Personen zu sharden⁶⁾, eine Installation ist ja immer über die Anzahl Mandanten skalierbar, und ein Mandant ist i.d.R. eine Firma⁷⁾. Somit werden es nicht 2 Milliarden Personen in einem Mandanten geben, sondern maximal tausende, was heutzutage die einfachste Datenbank handhaben kann.

Eine Person hat beliebig viele Kommunikationswege, z.B. E-Mail, Telefon, Fax, Facebook, Skype, Mobil, Twitter, usw. Da man mehrere Angaben zu einer Art machen kann, z.B. zwei oder drei E-Mail Adressen, handelt es sich hierbei um Entitäten, und nicht um Value-Objects. Die Identität ist noch eine surrogate ID, kann auch gar nicht die Kombination aus CommunicationWay⁸⁾ und dem Wert sein, weil auch diese doppelt sein können⁹⁾.

Eine Personkann beliebig verändert werden, aber nicht gelöscht.

• AddPerson: Neue Anrede hinzufügen
• CorrectPerson: Korrigieren. Ist nicht toll gewählt, aber man kann später noch ChangeName einführen, mit einer Begründung, z.B. Heirat, damit man in der Kontinuität unterscheiden kann zwischen einfachen Korrekturen und echten Änderungen.
• To-Do: Befehle für Kommunikationswege

• PersonAdded
• PersonCorrected
• To-Do: Ereignisse für Kommunikationswege