# 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.