-
Notifications
You must be signed in to change notification settings - Fork 0
Isolation Types
DUDA supports 4 isolation types. A project can have multiple types simultaneously.
Structure: Upper layer creates features → lower layers inherit selectively
Platform (HQ)
├── Organization (Region/Brand)
│ ├── Tenant (Store/Client)
│ │ └── Sub-tenant (Department)
Risk: Upper-only features leaking to lower layers
Example: Franchise system where HQ platform features shouldn't appear in store apps
Detection: grep -r "from.*platform/" src/tenant/
Structure: Shared codebase, per-organization data isolation
Shared Application Code
├── Org A data (filtered by org_id)
├── Org B data (filtered by org_id)
└── Org C data (filtered by org_id)
Risk: Missing tenant identifiers in DB queries → cross-tenant data exposure
Example: B2B SaaS where Company A sees Company B's data
Detection: DB queries missing WHERE org_id = ?
Structure: Multiple apps sharing packages in a monorepo
monorepo/
├── apps/admin/ ← should NOT import from apps/user/
├── apps/user/ ← should NOT import from apps/admin/
└── packages/ ← shared code, safe to import
Risk: Direct cross-app imports creating hidden dependencies
Example: Admin-only components imported in user app
Detection: grep -r "from.*apps/" src/
Structure: Independently deployed services communicating via APIs
Service A ──API──→ Service B
│ │
DB-A DB-B ← each service owns its DB
Risk: Direct DB access or function calls across service boundaries Example: Order service directly querying User service's database Detection: Cross-service DB connection strings, direct function imports
Most real-world projects combine types:
| Combination | Example |
|---|---|
| A + B | Platform with multi-tenant data isolation |
| B + C | Multi-tenant SaaS in a monorepo |
| C + D | Monorepo with microservice deployments |
| A + B + C | Enterprise platform with everything |
DUDA's duda init automatically detects which types apply to your project.