/* Page prose (ja) */
"DistributedWrappingUp" = "# まとめ\n\n**分散 actor** は、すでに知っている actor の真ん中にネットワークが落とし込まれたものです。そのたった 1 つの変更が下のすべてに波及し、そのどれも願って消せるものではありません。以下の要点は、ローカルな `actor` がほとんどいつも正しい最初の答えである理由についての、1 つの続いた論として読んでください。\n\n* **分散 actor** はローカルな `actor` モデルをプロセスとマシンをまたいで拡張します。`await` で呼び出すのと同じ感覚ですが、呼び出しはネットワークを越えるかもしれません。\n* それは 4 つの部品の上に成り立ちます。**`distributed actor`**、その **`distributed`** メソッド、**`ActorSystem`**（actor を見つけ出しメッセージを運ぶトランスポート）、そして actor を遠くから見つけられるようにするシリアライズ可能な **`ID`** です。\n* 分散呼び出しは `async` **かつ** `throws` です。`try` があるのは、ネットワークが本当に失敗しうるからです。タイムアウト、切れた接続、ダウンしたノード。失敗をめったにない驚きとして扱うのではなく、戻ってこない呼び出しに向けて設計しましょう。\n* 引数と戻り値は **`Codable`** でなければなりません。バイトとして移動するからです。[グローバル actor と Sendable](Global%20Actors%20and%20Sendable.playgroundchapter/Overview) の章の `Sendable` を、もう一歩進めたものです。ペイロードは、生きたオブジェクトや参照ではなく、小さく自己完結した値型（`Receipt` のような）として設計しましょう。\n* **位置透過性**は、actor がどこに存在しても同じやり方で呼び出せるようにしますが、コストは現実のものです。レイテンシ（数の少ない、より大きなメッセージを送る）、部分的な失敗、そしてシリアライズ。それらを念頭に置いて設計しましょう。\n* ほとんどのアプリ開発者にとって、これは*まれな*ニーズであり、最も関係が深いのはサーバーサイド Swift とクラスター化されたシステムです。1 つのプロセスに心地よく収まるシステムを分散させてはいけません。モデルを理解することのほうが、日常的にそれを使うことよりも重要です。\n\n[前へ](@previous)  |  9 / 9 ページ";
