Decide what belongs together
Business objects need a clear home. A domain plan names the business areas, the records they own and the records they use from elsewhere.
It also records the application’s tenancy choice. Those decisions guide the project structure while keeping shared references distinct from duplicated ownership.
Example — Share relationship records across the product
A customer-management module owns contacts and companies. Other modules can use those records while the plan keeps their primary ownership clear.
For engineers
Read a concrete module declaration
This module entry comes from Wonder CRM’s domain plan; the surrounding snapshot and other modules are omitted:
{
"relatedModuleId": "relationship-records",
"purpose": "Maintain the shared contact and company records that give workspace teammates a common view of customer and prospect relationships.",
"businessCapability": "Shared customer relationship record management",
"businessDomain": "Customer relationship management",
"primaryActors": [
"Founder or sales lead",
"Customer relationship owner"
],
"mainResources": [
"contact",
"company"
],
"supportingResources": [
"interaction"
],
"integrationSurfaces": [
"web workspace",
"customer record views"
]
},
mainResources establishes the module’s primary records. supportingResources describes records it uses without turning every reference into another owning module. Actors and integration surfaces explain the business context for that decomposition.
Keep the plan distinct from runtime declarations
| Decision | What still follows |
|---|---|
| Resource ownership | Compose and register the resource in the owning module |
| Relationship intent | Implement the actual relationship declaration and behavior |
| Tenancy | Configure the application’s scope and access behavior |
| Module purpose | Implement the capabilities that fulfill it |
Relationship cardinality and ownership intent do not themselves configure access permissions or deletion behavior. Those belong in the application’s actual declarations and implementation.
Carry tenancy into production work
Choose the primary scope for the application’s records:
| Choice | Intended use |
|---|---|
DomainPlanTenancyModel.ORGANIZATIONS | People collaborate inside shared organizations or workspaces |
DomainPlanTenancyModel.USERS | Each person’s records belong to that individual |
This selected member of a domain plan chooses shared workspaces:
// Import DomainPlanTenancyModel from @wildo-ai/saas-specifications.
tenancy: DomainPlanTenancyModel.ORGANIZATIONS,
The foundation uses a valid plan’s tenancy first. If it is absent, provide the explicit primary-scope answer, organizations or users; neither source means the foundation refuses to guess. Scope selection guides composition. Resource access rules still need their own declarations and verification.
Register the plan through the application’s domain-plan export and inspect the compiled artifact view. Review the resulting composition and relationships against the intent; the plan is product architecture, not the live resource registry.