===== Employee =====
Hierbei handelt es sich um eine Rolle, die eine Person annehmen kann. Der Employee ist dabei Mitarbeiter des eigenen Unternehmens, das durch den Mandanten repräsentiert wird. Zum Mitarbeiter gehören Daten wie die Personalnummer, der Angestellten Zeitraum und die Mitarbeiterfunktion.
==== Identität ====
Employee ist eine Rolle der Person, somit eine Entität im Person Aggregte. Die Identität der Rolle ist die der Person.
==== Index ====
Es gibt einen Index auf die Personalnummer, damit sie nicht doppelt vergeben werden kann. Hier gilt dasselbe wie für andere Indizes: Man kann es auch über //eventual consistency// lösen. Sobald von einer Stelle erkannt wird, dass es doppelte Personalnummern gibt, würde diese Stelle einen Fehler melden, und erst weiter machen können, nachdem der Konflikt aufgelöst wurde.
\\ \\
Nochmal generell: Solange Bereiche eine doppelte Personalnummer erlauben, kann man sie ja doppelt vergeben lassen. Das mit eventual consistency zu prüfen ist dann eine extra Sicherheit. Wenn ein Bereich nun per se Fehlerhaft arbeiten würde, wenn es eine doppelte Personalnummer gibt((das kann auch ein Export an ein Fremdsystem sein)), würde der Bereich das als Fehler melden, und das Problem kann behoben werden.
\\ \\
Die Konsequenz daraus ist, dass man nicht Aggregate übergreifende Indizes für die Eindeutigkeit von Werten bauen muss, nur weil man meint, dass es so sein muss. Das kann genauso gut so gebaut sein, wie hier mit eventual consistency beschrieben.
==== Inhalte ====
Die Mitarbeiter Rolle enthält (vorerst) keine weiteren Entitäten oder Value Objects.
==== Regeln ====
Aktuell kann eine Person um eine Mitarbeiter Rolle erweitert werden, wobei die einzige Regel ist, dass das Eintrittsdatum((falls angegeben)) nicht hinter dem Austrittsdatum((falls angegeben)) liegen darf. Auch die Personalnummer kann beliebig verändert werden, solange sie nicht gleichzeitig((//Gleichzeitig// ist in einem Event Sourced System für unabhängige, partitionierbare Aggregtes nicht wirklich definiert)) doppelt vorhanden ist.
\\ \\
Sinnvoll wäre es natürlich, die Daten zur Anstellung((Eintritt, Austritt, Funktion, Personalnummer)) temporal zu halten, so z.B. dass der Mitarbeiter vom 1.1.2000-31.12.2005 die Personalnummer 000123 hatte, ab dem 1.1.2006 die Personalnummer 321000 hat((Entweder durch eine Neuanstellung, eine Beförderung, oder durch eine Umstellung des Buchführungs Systems)). Das kann in Version 3.0 dazu gebaut werden.
==== Befehle ====
  * AddEmployement: Mitarbeiter Rolle einer Person hinzufügen
  * ChangeEmployement: Änderung des Zeitraums((z.B. durch Austritt)), oder der Funktion((z.B. durch Beförderung)). Man könnte das noch expliziter gestalten, z.B. mit EndEmployment, PromoteEmployee, usw.
  * SetEmployeeKey: Das ist ein anderer Befehl als ChangeEmployement, weil sich die Personalnummer i.d.R. bei einem Austritt oder einer Beförderung nicht ändert.
  * GenerateEmployeeKey: Für den Fall, dass die Personalnummer nicht manuell vergeben wird. Die Domäne weiß, wie die Personalnummer generiert wird((Bzw. wird ihr dafür der Generator über //Service Locator/Dependency Injection// übergeben)), es wird aber von Außen((User oder Applikation selbst)) entschieden, wann die Personalnummer generiert werden muss.
==== Ereignisse ====
  * EmployementAdded
  * EmployementChanged
  * EmployeeKeySet
  * EmployeeKeyGenerated