===== Person =====
Hierbei handelt es sich um die Person selbst((Im Grunde das //Haupt-Aggregate// dieses Moduls)), 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((Auch in anderen Anwendungen als PRO·M)) verwendet werden kann, wo eine (erweiterbare) Person benötigt wird.
==== Identität ====
Eine Person wird durch die Kontinuität identifiziert. Sie hat einen Namen und einen Matchcode((Alias, über den sie gesucht und angezeigt wird)), 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((Historie)) 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.
==== Index ====
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((Oder verteilte Transaktionen verwendet werden)).
\\ \\
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//((Auf mehrere Datenbanken, bzw. Server zu verteilen)), eine Installation ist ja immer über die Anzahl Mandanten skalierbar, und ein Mandant ist i.d.R. eine Firma((Konzerne werden auf mehrere Mandanten aufgeteilt)). Somit werden es nicht 2 Milliarden Personen in einem Mandanten geben, sondern maximal tausende, was heutzutage die einfachste Datenbank handhaben kann.
==== Inhalte ====
=== Entitäten ===
== Kommunikationswege ==
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((die pro Kommunikationsweg für die Typisierung referenziert wird)) und dem Wert sein, weil auch diese doppelt sein können((zu überlegen wäre, das zu ändern, indem man einfach erst pro Script doppelte Daten löscht)).
==== Regeln ====
Eine Personkann beliebig verändert werden, aber nicht gelöscht.
==== Befehle ====
  * 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
==== Ereignisse ====
  * PersonAdded
  * PersonCorrected
  * To-Do: Ereignisse für Kommunikationswege