anchor.diff:  #### Model für eine verifizierte Email
   
   ' Wenn ein neuer Kunde eine Email eingibt, dann muss diese oft erst verifiziert werden
  -' Bis zu dieser Verifizierung, handelt es sich um eine nicht verifizierte Email
  -' Erst nach der Verifizierung, wird daraus eine verfizierte Email (der Beweis ist ein Token)
  -' Die beiden Zustände einer Email als DU modelieren
  +' Bis zu dieser Verifizierung handelt es sich um eine nicht verifizierte Email
  +' Erst nach der Verifizierung wird daraus eine verfizierte Email (der Beweis ist ein Token)
  +' Die beiden Zustände einer Email als DU modellieren
   
   *)
       type VerifizierteEmail = { Email:Email; Verifikation: EmailVerificationToken; }
  
positive.code: - Typ System begünstigt Komposition<!-- .element: class="fragment grow" -->
  - DU erlauben eine kompakte Darstellung von Zuständen
  
  ' - In C# oder in Java, ist die Hemmschwelle relativ hoch neue Types zu erstellen. Es gibt sogar das code smell "Primitive Obsession", kein Scherz
  ' - Komposition erlaubt es einfache Typen zu immer komplexeren zusammenzufassen.  Es ist erstaunlich wie viel dann auf einer Seite passt
  ' - Macht Nicht Programmierern weniger Angst
  ' - Bei Programmierung von Fachanwendungen, geht es oft darum dass ein Objekt mehrere Zustände haben kann.  Jedes Zustand hat wiederum eigne Operationen, Fähigkeiten. DU erlauben diese sehr gut darzustellen
  
  ---
  ### DDD und F#
  
negative.code:     | true,value -> sprintf "Value parsed is %s" (value.ToString())
      | false,_ -> "Value couldn't be parsed" 
  
  let tryParseResult = Int32.TryParse "Keine Zahl" |> showParseResult
  let tryParseResult' = Int32.TryParse "1" |> showParseResult
  
  
  (** <div style="display: none" > *)
  (*** define-output:Tuple-TryParsePatternMatching ***)
  printf "result = %A | " tryParseResult 
  printf "result' = %A" tryParseResult'
  (** </div> *)
  
  (*** include-output: Tuple-TryParsePatternMatching ***)
  