Asset Ownership and Boundaries

Summary

Source-backed map of what the Asset Service owns in its own database versus what it only points at across a service boundary. Every association is classified so that no relationship is mistaken for a cross-service foreign key.

Audience

Backend engineers, database reviewers, architects, QA, support, operations, security reviewers, and product owners.

Overview

The Asset bounded context persists into a dedicated logical schema owned solely by the Asset Service. Inside that schema the service owns the canonical Asset aggregate, its child rows, and its own evidence and messaging tables. Everything the aggregate says about employees, workflow state, document bytes, notifications, and the monolith is stored as a plain identifier — there are no foreign keys that reach into another service's data. The rule below is absolute: cross-service links are values, not relational constraints.

Confirmed persistence behavior

• Canonical asset aggregate ownership. The Asset aggregate root (the Assets table) is owned outright by the Asset Service. It holds tenant scope, category, lifecycle status and condition, the assignee pair, workflow linkage, compatibility identity, and timestamps.
• Assignment-history ownership. AssetAssignmentHistory rows are owned children of Asset, linked by a database-enforced, required, cascade foreign key on AssetId. They are an append-only historical log owned entirely within the schema.
• Document-reference ownership vs document-byte ownership. The Asset Service owns only the AssetDocumentReference row — the metadata pointer (type, file name, content type, storage key, size, hash, uploader). The document bytes are never stored in this database; they are owned by the Document Service and reached only through identifier fields.
• Workflow-state ownership. Approval workflow state is owned by the Workflow Service. The aggregate keeps only a nullable WorkflowInstanceId value pointing at that external instance; no workflow rows live in this schema.
• Employee identity ownership. Employee and platform-user identity is owned by the Employee/Identity services. The aggregate stores AssignedToUserId and LaborId as plain integers with no foreign key.
• Notification ownership. Delivery of notifications is owned by the Notification Service. The Asset Service only emits lifecycle events to its outbox; it stores no notification state.
• Compatibility identity. CompatId is a property owned by the Asset aggregate itself. It mirrors the monolith AssetRecord.Id value space so legacy consumers can resolve the same asset, but it is a value the Asset Service owns and guards with a unique index — not a foreign key into the monolith.
• Gateway ownership. The gateway owns request routing only; it owns no asset data and holds no persistence in this schema.

Classification

Association	Owning side	Classification
Asset → AssetAssignmentHistory	Asset Service	Database-enforced relationship (required, cascade FK)
Asset → AssetDocumentReference	Asset Service	Database-enforced relationship (required, cascade FK)
Asset.AssignedToUserId → platform user	Employee/Identity	Identifier-only reference (external-service)
Asset.LaborId → legacy employee	Employee/Identity	Identifier-only reference (external-service)
Asset.WorkflowInstanceId → workflow instance	Workflow Service	External-service reference (identifier-only)
AssetDocumentReference document/storage ids → blob	Document Service	External-service reference (identifier-only)
Notification delivery	Notification Service	External-service reference (event-driven, no stored link)
Asset.CompatId → monolith AssetRecord.Id space	Asset Service (mirrors monolith)	Compatibility reference
Gateway routing	Gateway	Frontend/routing-derived association (no data ownership)

None of the identifier-only, external-service, or compatibility references is backed by a database foreign key. Only the two parent-child links inside the aggregate are relationally enforced.

Requires confirmation

• Authorization governance over cross-boundary references (endpoints are anonymous and tenant-scoped in the current foundation).
• Production ownership of routing configuration and any reconciliation between CompatId and the retiring monolith record space.

Diagram

Related Articles

• Asset database documentation
• Asset Storage

See Also

• Document Reference Storage
• Workflow Reference Storage
• Compatibility Identity Storage

Keywords

• Asset data ownership
• Bounded context boundaries
• Draft database documentation

Source References

• microservices/src/asset-service/Domain/Asset/Asset.cs
• microservices/src/asset-service/Infrastructure/AssetDbContext.cs
• microservices/src/asset-service/Domain/Repositories.cs

Revision Information

• Status: Draft
• Last reviewed: 2026-07-17
• Review cycle: Quarterly