jonnify·bcs /bcs/elixir-core/otp-application/the-boundary

B2.1.1 · dive 1 of 6 · module B2.1

The boundary is the export list.

A system’s public functions are its whole surface; the table is :private. Only a branded id and a message about it cross — never a reference to the state.

The export list as the boundary; the table sealed; an id crossing. Select a part.
the export list = the boundaryput/3get/2window/3page_desc/2placement/1 EchoData.Bcs.PropertyStore :private :ordered_setno caller reaches it {id} + a messagea reference: refused
readout · Select a part. A system’s export list is its boundary; the ETS table is :private; only a branded id and a message about it cross, never a reference.
§1

The idea

echo_data · bcs/property_store.ex

In BCS a system is a module, and the module’s exported functions are the whole of its surface. EchoData.Bcs.PropertyStore exports put/3, get/2, window/3, page_desc/2, and placement/1 — and that list is the system. Everything else is private: the ETS table the store owns is opened :private, so no other process can read or write it, not even by accident.

The boundary decides what may cross, and only two things may. A branded id crosses — the 14-byte name that is the table’s only key — and a message about that id crosses: put this value, get that one, give me the window between these two. A reference to the state never crosses, because there is no reference to hand out; the state lives behind the export list, reachable only by asking the owner.

This is the Part I law made concrete in a single Elixir module. Codemojex draws the same line around a room: the room exports join, guess, leave — commands naming a player and a round — and never exposes its board. A caller plays the game by sending messages about ids, and the system that owns the board is the only thing that touches it.

§4

The doors

the sibling courses
§2

References

sources · related

Sources

Related