Series map

• The Gnome Village: processes as polite workers with private backpacks.
• Supervisors Are Managers: supervisors as calm managers who restart gnomes without drama.
• This post: why domains and flows matter before we dive into them.
• Domains Own Code and Data: carving modules and OTP apps into bounded contexts. New today.
• Flows Keep Work Moving: data, message, process, and call flows. New today.
• Putting It Together: turning the checklist into a running system. New today.
• Next: process archetypes and flow choreography (coming soon).

Glossary:

• Resource owner = the process that owns mutable state for a domain object.
• Request owner = the process coordinating one user request end-to-end within a domain.
• Adapter = the boundary process that talks to an external system.
• Orchestration = the domain that coordinates multi-step work across other domains.

Introduction

We started this series by meeting the gnomes: tiny BEAM processes with private backpacks, polite mailboxes, and no interest in shared memory. In the last post we met their supervisors, the managers who calmly restart whoever drops a hammer. Together they gave us a village that keeps working even when a gnome explodes. Processes are cheap, isolation is free, and supervision trees are better than trust falls.

Teams still end up with machine parks because they wrap threads in classes, share mutable state “just this once,” and trust the global lock. When one thread stalls, everything piles up behind it. Debugging becomes sorting through shared variables to guess who touched what. Compliance shifts into endless reviews of access control. In the gnome village you spawn another process, send a message, restart the failed worker, and keep going. Predictable beats clever machinery.

This post is the hinge between the metaphor and the mechanics. Processes (gnomes) are the runtime, but domains decide how code and state are organized, and flows define how work travels between them. Align those three layers and the system stops fighting you. Ignore them and you get accidental coupling: an API reaching into the wrong ETS table, a supervisor tree overloaded with synchronous calls, dashboards lighting up because no one knows where the flow broke. From here on, “resource owner” means “the process that owns mutable state,” “request owner” is the process running an end-to-end request, and an “adapter” is the boundary to an external system.

Compliance breaks when architecture drifts

At Code BEAM Berlin I said compliance is just good engineering done on purpose. Auditors ask for logging, isolation, and predictable behavior because those are the only ways to prove who did what and when. Tie code, state, and runtime behavior into one lump and you lose that evidence. The regulator is not the problem. Your architecture is.

Systems fail when code, state, and call patterns drift apart. You add one bypass, then a shared cache, then a blocking call in a handler, and suddenly the code and the runtime disagree. The result is stale data, full mailboxes, and synchronous chains nobody planned. Fix the boundaries. The boundaries are what we call domains.

Processes

Gnomes are still the core unit. Each process owns its heap, reads scrolls from the code server, and works under a supervisor that can restart it without ceremony. Processes are the runtime execution layer; they carry the work but they do not define the structure. Keep them small, give them one job, and let supervision trees isolate failure.

Domains

Domains are the structural layer. A domain owns its types, invariants, and transformations. On the BEAM, that means modules and OTP apps that contain code and state for one bounded area—users, orders, ledgers, adapters. Domains give the processes something coherent to execute so state does not drift into random helper modules.

Flows

Flows are the choreography layer. They define how calls, messages, data, and processes move between domains. When the flows are explicit, you know which protocol crosses each boundary, which process owns each step, and which metrics tell you when something is stuck. Flows keep the gnomes polite when they have to cross domain borders.

Where we go next

From here, hop to Domains Own Code and Data for the practical slicing patterns, then to Flows Keep Work Moving for the checklists. Finish with Putting It Together to see how it lands in a payment-style system. After that we will head into process archetypes.

Prev: Supervisors Are Managers | Next: Domains Own Code and Data