/* Page prose (de) */
"DistributedWrappingUp" = "# Zusammenfassung\n\nEin **verteilter Actor** ist der Actor, den du bereits kennst, mit einem Netzwerk mittendrin. Diese eine Änderung strahlt in alles darunter aus, und nichts davon lässt sich wegwünschen. Lies die Kernaussagen als ein einziges durchgehendes Argument dafür, warum ein lokaler `actor` fast immer die richtige erste Antwort ist.\n\n* Ein **verteilter Actor** erweitert das lokale `actor`-Modell über Prozesse und Maschinen hinweg: dasselbe Gefühl von `await`-zum-Aufrufen, aber der Aufruf kann ein Netzwerk überqueren.\n* Er ruht auf vier Teilen: dem **`distributed actor`**, seinen **`distributed`**-Methoden, einem **`ActorSystem`** (dem Transport, der Actors auffindet und Nachrichten verschickt) und einer serialisierbaren **`ID`**, die einen Actor aus der Ferne auffindbar macht.\n* Verteilte Aufrufe sind `async` **und** `throws`. Das `try` ist da, weil das Netzwerk wirklich fehlschlagen kann: Zeitüberschreitungen, abgebrochene Verbindungen, ein ausgefallener Knoten. Entwirf für Aufrufe, die nicht zurückkommen, statt den Fehler als seltene Überraschung zu behandeln.\n* Argumente und Rückgabewerte müssen **`Codable`** sein, weil sie als Bytes reisen: `Sendable` aus dem Kapitel [Globale Actors und Sendable](Global%20Actors%20and%20Sendable.playgroundchapter/Overview), einen Schritt weitergeführt. Entwirf Nutzlasten als kleine, in sich geschlossene Werttypen (wie `Receipt`), nicht als laufende Objekte oder Referenzen.\n* **Standorttransparenz** lässt dich einen Actor auf die gleiche Weise aufrufen, egal wo er lebt, aber die Kosten sind real: Latenz (sende wenigere, größere Nachrichten), Teilausfall und Serialisierung. Entwirf mit ihnen im Hinterkopf.\n* Für die meisten App-Entwickler ist dies ein *seltener* Bedarf, am relevantesten für serverseitiges Swift und geclusterte Systeme. Verteil kein System, das bequem in einen Prozess passt; das Modell zu verstehen ist wichtiger, als es täglich zu benutzen.\n\n[Zurück](@previous)  |  Seite 9 von 9";
