How does the Law of Demeter generalise beyond single objects — to modules, packages, and service boundaries — and what are its known limitations at that scale?

## Scaling the principle up The object-level rule — *only message immediate collaborators* — has a direct analogue at every larger granularity, because the underlying idea is granularity-independent: **don't encode knowledge of another unit's internal composition.** ### Where it shows up architecturally **1. DDD aggregates.** An aggregate is a cluster of objects with one **root**; external code may hold a reference to the root only, and must reach internals through it. This is the Law of Demeter promoted to an invariant-protection rule: if outsiders could grab `order.lines()` and mutate a line, the root could no longer guarantee "total must equal the sum of lines". **2. Facade pattern.** A single entry point over a subsystem so clients don't navigate its parts. Textbook LoD at module scale. **3. API gateway / Backend-for-Frontend.** Clients call one endpoint instead of orchestrating five services; they never learn the internal service topology. Same principle, network edition. **4. Anti-corruption layer (DDD).** Translates a foreign bounded context's model into yours so its *structure* does not leak inward — LoD applied across an ownership boundary, which is the highest-value place to apply it. **5. Enforced module/package dependency rules.** Declaring which packages a module may depend on (module systems, ArchUnit-style tests, Spring Modulith `allowedDependencies`) is the **class-level** Law of Demeter mechanised: the set of types a unit may name is declared, and anything else is a stranger. **6. Law of Demeter for data.** Don't let a caller depend on the *shape* of a payload three levels deep; expose a flat, intent-shaped contract. Wire schemas that mirror internal structure are train wrecks with a serializer attached. ### The limitations — this is what separates a principal answer **a) Chattiness / latency inversion.** In-process delegation is free. Across a network it is not: each hidden hop can be a round trip. Architecturally you often want the *opposite* of LoD's naive shape — one coarse-grained call that returns a composed result ("chunky, not chatty"), which is precisely a caller reaching for a *composed* view. The resolution is that LoD forbids *the client knowing the traversal*, not the *server performing* it — so composition belongs behind the boundary (gateway, read model), not in the client. **b) Facades become god interfaces.** Every new client need adds a method. Over years the facade is a 300-method interface that couples everyone to everything — the Middle Man smell at architectural scale, with the added problem that it becomes a change bottleneck and a deployment coupling point. **c) Pass-through layers.** Strict layer-by-layer delegation yields controllers that call services that call services that call repositories, each adding nothing. The delegation cost that is annoying inside a class is expensive across layers, because each layer has its own DTOs, tests, and mappers. **d) LoD only addresses *structural* coupling.** Two services can share zero types and still be lethally coupled — on ordering, on a shared database, on an implicit state machine, on message semantics. **Connascence** gives a richer vocabulary here (name, type, meaning, position, algorithm, timing, execution order, identity); LoD roughly targets connascence of *position/structure* and *name*, and is silent about *timing*, *execution order*, and *identity* — often the couplings that actually cause outages. **e) Hiding vs removing.** Wrapping a transitive dependency behind a method makes it invisible, not absent. If service A's response *semantically* depends on service C's data, you still have an availability and change dependency on C. The org chart, not the call graph, is often the truer picture (Conway's Law). **f) Traversal has to live somewhere.** Query/reporting, serialization, and ETL genuinely need whole-graph access. The mature answer is to confine it — dedicated read models, mappers, a CQRS query side — rather than pretend it doesn't exist. ### The synthesis to state "Law of Demeter is a specific, useful, *narrow* tool: it limits how much a unit knows about another unit's internal composition. Scaled up it produces aggregates, facades, gateways, anti-corruption layers, and enforced module boundaries. But at scale it can be actively wrong if applied naively — hiding hops across a network costs latency, and it addresses only one of many coupling dimensions. I use it as a detector for structural leakage, and reach for connascence and explicit contracts to reason about the rest."