Stage 7 · Master
Kicking Off Fieldwork
Choosing Fieldwork's Domain
Why a boring multi-tenant workspace/task API was picked as the vehicle, and what stays out of scope.
Why a Boring Domain
Fieldwork is a multi-tenant workspace and task-tracking API — teams, projects, and tasks, scoped per tenant. It's an intentionally unoriginal domain. An interesting domain competes with the lesson for attention; a boring one disappears into the background so every module stays about the stack decision at hand, not about explaining business rules.
The domain also needed to be small enough to hold in your head across eleven modules, but rich enough to justify multi-tenancy, role-based permissions, and cross-entity queries — the three things this course actually needs a real schema for.
The Core Entities
- Tenant — the top-level isolation boundary; every other entity belongs to exactly one tenant.
- Workspace — a tenant can have multiple workspaces (e.g. departments or client accounts).
- Membership — links a user to a workspace with a role (owner, admin, member).
- Project — belongs to a workspace, groups related tasks.
- Task — belongs to a project; has an assignee, status, and due date.
The entity list looks almost too simple to teach anything. That's intentional — the hard part of this course isn't the entities, it's making tenant isolation, caching, and eventing all correctly aware of the Tenant → Workspace → Project → Task chain at every layer.
What Is Deliberately Out of Scope
No billing, no file storage, no real-time collaboration, no mobile clients. Anything that would pull focus onto a new domain problem (payments correctness, binary storage, WebSocket state) is left out — Fieldwork exists to teach the backend stack, not to be a complete product.
Why This Shape Forces Real Decisions
Every module in this course maps back to something this shape genuinely requires: the Tenant boundary forces the shared-schema-vs-schema-per-tenant decision in Module 3. Workspace-scoped Membership forces the permission model in Module 5. A Project having many Tasks with status changes is exactly the kind of write that's worth publishing as an event in Module 7, once notifications or reporting services need to react to it without being called synchronously.
None of this is presented as a finished product. As later modules land, this lesson is the one place that should stay accurate to the actual schema — if something changes, it changes here first.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.