Bounded Contexts¶
Target Architecture — Final-State Design
This page describes the final-state domain decomposition of the Runtime & Cloud Platform. Each bounded context owns its aggregates, services, and stores, and communicates with the others only through the canonical event envelope.
The Runtime & Cloud Platform is decomposed into six bounded contexts. Together they cover the full lifecycle of a generated SaaS runtime: provisioning an environment, deploying workloads into it, configuring and binding secrets to those workloads, isolating tenants, keeping workloads healthy and elastic, and reconciling actual state against desired state.
Context Map¶
flowchart TB
subgraph REI["Runtime Environment & Inventory"]
RE["RuntimeEnvironment"]
RS["RuntimeService"]
end
subgraph DEP["Deployment"]
RD["RuntimeDeployment"]
end
subgraph CFG["Configuration & Secrets"]
RConf["RuntimeConfiguration"]
SB["SecretBinding"]
end
subgraph ISO["Tenant Isolation"]
TB["RuntimeTenantBinding"]
end
subgraph HS["Health & Scaling"]
HC["HealthCheckResult"]
SP["ScalingPolicy"]
end
subgraph DRIFT["Drift Detection"]
DF["RuntimeDriftFinding"]
end
REI -->|"environment ready"| DEP
DEP -->|"workload deployed"| HS
CFG -->|"config + secrets applied"| DEP
ISO -->|"tenant boundaries"| REI
HS -->|"health + scale signals"| DRIFT
DRIFT -->|"desired-state divergence"| DEP
REI -->|"inventory baseline"| DRIFT
Hold "Alt" / "Option" to enable pan & zoom
Context Catalog¶
| Bounded Context | Responsibility | Aggregate Roots | Owning Services |
|---|---|---|---|
| Runtime Environment & Inventory | Provision and track isolated runtime environments and the live inventory of generated components in them. | RuntimeEnvironment, RuntimeService |
RuntimeEnvironmentService, ServiceCatalogRuntimeService |
| Deployment | Roll generated workloads onto Azure compute with health-gated, reversible promotion. | RuntimeDeployment |
DeploymentService |
| Configuration & Secrets | Distribute versioned runtime configuration and bind workloads to Key Vault secrets via managed identities. | RuntimeConfiguration, SecretBinding |
RuntimeConfigurationService, SecretBindingService |
| Tenant Isolation | Translate generation-time tenant boundaries into enforced runtime isolation across compute, data, and quota. | RuntimeTenantBinding |
TenantRuntimeIsolationService |
| Health & Scaling | Continuously evaluate workload health and apply SLO-driven scaling policies. | HealthCheckResult, ScalingPolicy |
RuntimeHealthService, RuntimeScalingService |
| Drift Detection | Reconcile actual runtime state against desired state and surface divergence for remediation. | RuntimeDriftFinding |
RuntimeDriftDetectionService |
Context Relationships¶
- Runtime Environment & Inventory → Deployment — an environment must be provisioned and recorded in inventory before any
RuntimeDeploymentcan target it. The inventory baseline is also the source of truth for drift comparison. - Configuration & Secrets → Deployment — a deployment binds the versioned
RuntimeConfigurationandSecretBindingset for its target environment before workloads start. Secret values are never copied into config; bindings reference Key Vault. - Tenant Isolation → Runtime Environment & Inventory — tenant bindings constrain how environments and services are partitioned (shared, siloed, or pooled) and feed isolation guarantees into provisioning.
- Deployment → Health & Scaling — once a workload is deployed, Health & Scaling takes over continuous evaluation and elasticity.
- Health & Scaling → Drift Detection — health degradation and scaling actions are inputs to drift analysis (e.g. a workload running at an unexpected replica count or image version).
- Drift Detection → Deployment — when divergence from desired state is detected, remediation is expressed as a corrective
RuntimeDeployment(re-apply, redeploy, or roll back).
Anti-Corruption and Shared Kernel¶
- The desired state for every context is sourced from the DevOps / GitOps Platform (Git-declared manifests and Pulumi programs) and treated as authoritative; the Runtime & Cloud Platform never invents desired state.
- All contexts share the canonical event envelope and naming conventions as a shared kernel —
tenantId,projectId,moduleId,traceIdflow through every cross-context message. - Tenant identity (
RuntimeTenantBinding) is the cross-cutting isolation boundary respected by every context's stores and compute placement.