Skip to content

Domain Ownership Map

Purpose

Define clear ownership for each bounded context so decisions, reviews, handoff, and on-call responsibilities are unambiguous.

This map should be treated as an architecture boundary guide, not just a staffing note. As the repo grows, every change should make domain boundaries clearer rather than blur them.

Team Model (Current Small Team, Future Domain Owners)

  • Platform Lead (primary architecture owner)
  • Backend Engineer
  • Infra/SRE Engineer
  • Security Champion (can be part-time role)

Future target: each major domain should be understandable and maintainable by a domain owner, even if implementation starts in a shared monorepo.

Domain Model

The platform should be thought of as a set of separable domains: - IAM - Billing - Provisioning.Allocation - Provisioning.BareMetal.MAAS - Inventory.Catalog - App Platform - UX - Operations

Domain intent

Domain Scope
IAM identity, authn/authz, tenant/project membership, session/security posture
Billing ledger, metering, balance policy, payments integration
Provisioning.Allocation allocation lifecycle, runtime/node assignment, release/force-release
Provisioning.BareMetal.MAAS MAAS site policy, onboarding/reimage/decommission, reconciliation
Inventory.Catalog nodes, SKUs, capacity/availability, marketplace/catalog concerns
App Platform app/project-facing platform capabilities layered on top of core infrastructure
UX web app, CLI, SDKs, user/admin journeys; consumes domain contracts rather than owning business logic
Operations deploy/release, observability, environment management, runbooks, CI/CD
Read Models cross-domain query projections and cache contracts that serve product/ops dashboards

Important clarifications

  • Inventory and Catalog should be treated as one bounded context for now, but kept explicit because they are likely extraction candidates later.
  • Provisioning.Allocation and Provisioning.BareMetal.MAAS are related but distinct. The first manages allocation/runtime lifecycle; the second manages hardware/site lifecycle and external MAAS orchestration.
  • App Platform is a real domain, not just a UI area. It is the developer-facing platform layer built on top of core infrastructure domains.
  • UX includes the web app, CLI, and SDKs. These are experience surfaces, not owners of core domain logic.
  • KYC should not be modeled as a standalone domain initially. Treat it as a cross-domain flow rooted in IAM policy/verification and surfaced through UX.

Ownership Matrix

Bounded Context Primary Owner Secondary Owner On-Call Severity
IAM Backend Engineer Security Champion SEV-1
Billing Platform Lead Backend Engineer SEV-1
Provisioning.Allocation Platform Lead Backend Engineer SEV-1
Provisioning.BareMetal.MAAS Infra/SRE Engineer Platform Lead SEV-1
Inventory.Catalog Backend Engineer Platform Lead SEV-2
App Platform Backend Engineer Platform Lead SEV-2
UX Backend Engineer Platform Lead SEV-2
Operations Infra/SRE Engineer Platform Lead SEV-1
Security Controls & Reviews Security Champion Platform Lead SEV-1

Boundary Rules

  • Domain logic should live with the owning bounded context, not in UX surfaces.
  • Cross-domain coordination should happen through explicit APIs, workflows, events, or read models, not ad hoc direct coupling.
  • When touching a domain, prefer changes that make extraction/handoff easier later.
  • MAAS-specific behavior should be isolated under Provisioning.BareMetal.MAAS, not scattered across unrelated packages.
  • CLI/SDK helpers may adapt operator input formats (for example CSV-to-JSON conversion), but canonical control-plane contracts remain JSON/domain owned.
  • Cross-domain dashboard/read-model APIs must name an owning domain for source data and a BFF owner for composition. Redis cache entries are performance artifacts only and must not become ownership boundaries.

Change Approval Rules

  • Contract changes: owner + one secondary reviewer.
  • Security-sensitive changes: owner + security champion.
  • Billing/ledger changes: owner + platform lead mandatory.
  • Provisioning.BareMetal.MAAS changes: owner + infra-coupled reviewer mandatory.

Escalation Rules

  • SEV-1 incidents page primary + secondary immediately.
  • If unresolved in 30 min, escalate to platform lead.