Skip to main content
As an app grows, many parts of the code end up changing the same tables. A domain fixes this: a folder owns its tables, only that folder’s functions can write them, and everything else calls those functions. Reads stay shared, so views and joins keep working across the whole app. A small app doesn’t need any of this. Add a domain when a second area of your app appears.

Declare a domain

Put the tables in a file inside the folder:
bijection/orders/tables.ts
Then add one line to your schema:
bijection/schema.ts
There is still one schema, so a view or .reference() can use tables from any domain.

Write inside the folder

Import builders from the folder’s generated server file. They can write that folder’s tables and read everything else:
bijection/orders/payments.ts
Inside a folder, share code with plain helper functions, as you would anywhere else.

Call across folders

Code in another folder changes those tables by calling one of the folder’s functions. The call runs in the same transaction, and if it throws, only its own writes roll back:
bijection/billing/pay.ts
Writing to orders directly from billing is a type error, and it also fails at runtime with TableDomainRequired, because the check runs on the function that is actually running. Each cross-folder call has a small cost, so keep them to real changes of ownership rather than every line of shared logic.

Narrow a table further

.writers() still works on a table in a domain, and it only ever narrows. Use it to say that only one function may change a field: