Something is calculated, and then it has to go somewhere: a table, a screen, a topic, a file, or nowhere at all. The usual arrangement lets whatever computed the value also name its destination, and the two decisions travel together from then on. Here they do not — and the interesting part is not the design, it is that the separation leaves marks you can measure, including one test that could only pass if it were real.
When a value is computed in one place and lands in another, which of them is entitled to decide where it lands?
The paper's claim is not that the separation is elegant. It is that where these decisions are kept apart, four costs go to zero — and each has a baseline that pays something. The four changes are ordinary ones: send the same computed output somewhere else; add three views of one recorded order — a despatch view, a catalogue view, and a finance view whose figure is worked out inside the view rather than stored; let an observer be handed a value instead of asking for it; and test what was computed. Every row came from a test that ran for this page.
| The change being made | Kept apart | Kept together |
|---|---|---|
| Send the output to a different destination | 0 edits to the thing that computed it | One edit per destination |
| Add three views of one order, one of them computed in the view | 0 new methods in the domain | One domain method per view |
| Hand a value to an observer instead of being asked for it | 0 domain methods for either direction | The direction becomes the producer's business |
| Test the output end to end | 0 stand-ins | At least one — the port |
The third row is the one that is easy to skim past, so it is worth saying mechanically: asking is a query that returns the value, and being told is a reaction that carries the same value to the observer. Same knowledge, arriving two ways — and the producer names neither of them. The direction is chosen outside the thing that computed the value.
The last row is not a convenience. It is the paper's own falsifiable test, and it is worth stating as the paper does.
- A value is computed and read back end to end with no destination bound at all — no sink, no port, no stand-in for output. The test needs none.
- Were the destination the producer's, that test could not run without it: to exercise what is computed you would first have to say where it goes.
- The same projection survives replay with nothing bound. And the contrast is measured rather than asserted: the ports-and-adapters version of the same output test has to stand up at least one double, because there is a port to double. Inversion moves a dependency. This one removes it.
The four laboratories are published as source, but the test project they belong to is not in the public runtime, so it was rebuilt from what their own imports ask for — the runtime, Choreography and MSTest, nothing else.
- Fourteen tests passed, one was skipped, none failed, at the runtime commit the laboratories pin.
- The skipped one is the only test that reaches two real database products, which need servers this machine does not run.it self-skips rather than failing, by its own design
- Everything on this page comes from the fourteen that ran.
So the destination-swap row is measured here for format, for pull against push, and against the baseline that pays an edit per destination — but not against two live database servers. That part is the laboratory's own result, not this page's.
Two limits, and the second is the paper's own about itself.
- One of the two boundaries is not fixed. Whether a given notion belongs to what exists or only to what becomes observable is a modelling judgement, decided per concept, and either answer can be right. What does not move is the other boundary: no refinement of how a value is computed will ever yield where that value is kept.
- It is an existence proof that the separation is buildable and has measurable consequences. It is not a claim that it is cheaper, faster, or right for a given system.