/*:#localized(key: "DistributedFourPieces")
 # The four pieces

 Four things work together. It's worth naming each one.

 ---

 ## 1. The `distributed actor` itself

 The type. Like a local actor, it owns isolated state. Unlike a local actor, it
 *must* be associated with an actor system, and it gains an identity that can be
 handed to other processes (more on that in a moment).

 ---
 
 ## 2. `distributed` methods

 The subset of methods you expose across the network. Each one is a potential
 **remote message**. Anything not marked `distributed` stays private to whoever
 holds a local reference.

 ---
 
 ## 3. The `ActorSystem`: the transport and runtime

 This is the piece with no local-actor equivalent, and it's the heart of the
 whole model. An **actor system** is the runtime that actually locates actors
 and carries messages between them: it assigns identities, serializes
 arguments, sends bytes over some connection, and delivers the call on the far
 side.

 You don't usually write one yourself. You use an existing implementation. The
 most prominent in 2026 is **`ClusterSystem`**, from Apple's open-source
 Distributed Cluster package, which links server-side Swift processes into a
 cluster. The toolchain also ships a `LocalTestingDistributedActorSystem` for
 exercising distributed code in tests without real networking. Either way, the
 actor system is a *dependency you bring in*, which is exactly why this doesn't
 run in Swift Playground.

 You hand the system to an actor when you create it:

 ```swift
 // `system` is an already-running ClusterSystem.
 let ledger = Ledger(actorSystem: system)
 ```

 That `actorSystem:` parameter isn't one you write by hand: the compiler
 synthesizes an initializer that takes it and wires it up. The system is now
 responsible for this actor: it gave it an identity and it knows how to route
 messages to it.

 ---
 
 ## 4. The `ID`

 When the actor system adopts an actor, it stamps it with an **`ID`**, a
 unique, serializable name for *this specific actor instance*, drawn from the
 system's own `ActorID` type. The ID is what makes an actor findable from
 another process.

 If Branch A knows the ID of a ledger living on Branch B's server, it can
 **resolve** a reference to it and start calling methods, without ever holding
 the real object:

 ```swift
 // Branch A resolves a remote ledger it never constructed.
 let remoteLedger = try Ledger.resolve(id: knownID, using: system)
 try await remoteLedger.deposit(50)
 ```

 `resolve(id:using:)` doesn't fetch the actor's state or copy it over. It
 returns a **remote reference**, a local stand-in that forwards every call
 across the network to the real actor. The state stays put on Branch B; only
 the *messages* travel.

 [Previous](@previous)  |  page 4 of 9  |  [Next: Async and Throws](@next)
 */
