/* Page prose (de) */
"DistributedFourPieces" = "# Die vier Teile\n\nVier Dinge arbeiten zusammen. Es lohnt sich, jedes einzeln zu benennen.\n\n---\n\n## 1. Der `distributed actor` selbst\n\nDer Typ. Wie ein lokaler Actor besitzt er isolierten Zustand. Anders als ein lokaler Actor *muss* er mit einem Actor-System verknüpft sein, und er erhält eine Identität, die an andere Prozesse weitergegeben werden kann (mehr dazu gleich).\n\n---\n\n## 2. `distributed`-Methoden\n\nDie Teilmenge der Methoden, die du über das Netzwerk offenlegst. Jede ist eine potenzielle **Fernnachricht**. Alles, was nicht als `distributed` markiert ist, bleibt privat für den, der eine lokale Referenz hält.\n\n---\n\n## 3. Das `ActorSystem`: Der Transport und die Laufzeitumgebung\n\nDies ist der Teil ohne Entsprechung beim lokalen Actor, und er ist das Herzstück des gesamten Modells. Ein **Actor-System** ist die Laufzeitumgebung, die tatsächlich Actors auffindet und Nachrichten zwischen ihnen befördert: Es weist Identitäten zu, serialisiert Argumente, sendet Bytes über irgendeine Verbindung und liefert den Aufruf auf der anderen Seite aus.\n\nNormalerweise schreibst du keins selbst. Du verwendest eine bestehende Implementierung. Die prominenteste im Jahr 2026 ist **`ClusterSystem`**, aus Apples quelloffenem Distributed-Cluster-Paket, das serverseitige Swift-Prozesse zu einem Cluster verknüpft. Die Toolchain liefert außerdem ein `LocalTestingDistributedActorSystem` mit, um verteilten Code in Tests ohne echtes Netzwerk zu erproben. So oder so ist das Actor-System eine *Abhängigkeit, die du mitbringst*, was genau der Grund ist, warum das nicht in Swift Playground läuft.\n\nDu übergibst das System an einen Actor, wenn du ihn erstellst:\n\n```swift\n// `system` is an already-running ClusterSystem.\nlet ledger = Ledger(actorSystem: system)\n```\n\nDiesen `actorSystem:`-Parameter schreibst du nicht von Hand: Der Compiler synthetisiert einen Initialisierer, der ihn entgegennimmt und ihn verdrahtet. Das System ist jetzt für diesen Actor verantwortlich: Es hat ihm eine Identität gegeben und weiß, wie man Nachrichten an ihn leitet.\n\n---\n\n## 4. Die `ID`\n\nWenn das Actor-System einen Actor aufnimmt, prägt es ihm eine **`ID`** auf, einen eindeutigen, serialisierbaren Namen für *genau diese Actor-Instanz*, entnommen aus dem eigenen `ActorID`-Typ des Systems. Die ID ist das, was einen Actor aus einem anderen Prozess auffindbar macht.\n\nWenn Filiale A die ID eines Hauptbuchs kennt, das auf dem Server von Filiale B lebt, kann sie eine Referenz darauf **auflösen** und anfangen, Methoden aufzurufen, ohne jemals das echte Objekt zu halten:\n\n```swift\n// Branch A resolves a remote ledger it never constructed.\nlet remoteLedger = try Ledger.resolve(id: knownID, using: system)\ntry await remoteLedger.deposit(50)\n```\n\n`resolve(id:using:)` holt weder den Zustand des Actors noch kopiert es ihn herüber. Es gibt eine **Fernreferenz** zurück, einen lokalen Stellvertreter, der jeden Aufruf über das Netzwerk an den echten Actor weiterleitet. Der Zustand bleibt an Ort und Stelle in Filiale B; nur die *Nachrichten* reisen.\n\n[Zurück](@previous)  |  Seite 4 von 9  |  [Weiter: Async und throws](@next)";
