distribution-patterns
Distribution Patterns
These are the patterns about communicating across a boundary (process, network, or layer). They address one root problem: crossing a seam safely and cheaply without leaking the internals on either side. Two patterns make up this skill:
- Remote Facade — the operation contract you expose to callers (coarse-grained, consumer-shaped).
- DTO (Data Transfer Object) — the data shape that travels across the seam.
Remote Facade is most often the external-facing contract (a REST endpoint, GraphQL mutation, gRPC method, CQRS command, message handler). A DTO is the data shape used both at that external boundary and at internal seams (between the application layer and the presentation layer, or across bounded contexts). The distinction is operation vs data, not strictly external vs internal — but the motivation in both cases is the same: don't drag the internal object model across the wire.
Remote Facade
A Remote Facade is a coarse-grained facade over a web of fine-grained objects, applied specifically to make remote calls cheap. See remote-facade.md for the full definition, rules, tradeoff, and examples. Key constraints: the facade holds no domain logic and is the only remote surface (the objects beneath it are in-process with no remote interface), and the contract is shaped around consumer needs, not the object model.
DTO (Data Transfer Object)
A DTO is a simple structure for moving data across a boundary — deliberately not a domain object. It keeps the API contract independent from the persistence/domain model so each can evolve for its own reasons. See dto.md for the full treatment, why domain objects don't belong on the wire, and the CQRS angle (Commands/Queries/Responses/Events are explicit DTOs).